Meny

SDET intervju spørsmål og svar (komplett guide)

sdet interview questions

Prøv Instrumentet Vårt For Å Eliminere Problemer

Les denne komplette guiden til Software Development Engineer i testintervjuer for å vite formatet og hvordan du kan svare på SDET-intervjuspørsmålene som ble stilt i de forskjellige rundene:

I denne opplæringen vil vi lære om noen vanlige intervjuspørsmål for SDET-rollene. Vi vil også generelt se det felles mønsteret til intervjuene og dele noen tips for å utmerke seg i intervjuene.

Vi bruker Java-språk for kodingsproblemene for denne opplæringen, men de fleste SDET-opplæringene er språkagnostiske, og intervjuere er generelt fleksible rundt språket kandidaten velger å bruke.

SDET intervju spørsmål og svar

Hva du vil lære:

SDET Intervju Forberedelse Guide

SDET-intervjuer, i de fleste av de beste produktselskapene, er ganske like måten intervjuer blir gjennomført for utviklingsroller. Dette er fordi det forventes at SDET-er også vet og forstår stort sett alt som utvikleren vet.

Det som er forskjellig er kriteriene som SDET-intervjuobjektet blir vurdert på. Intervjuer for denne rollen ser etter kritiske tenkeevner, samt om personen som blir intervjuet har praktisk erfaring med koding og har et øye for kvalitet og detaljer.

Her er noen punkter som noen som forbereder seg på et SDET-intervju i stor grad bør fokusere på:

php intervju spørsmål og svar for 1 års erfaring
  • Siden disse intervjuene mesteparten av tiden er teknologi / språkagnostiske, må kandidater derfor være villige til å lære ny teknologi (og utnytte eksisterende ferdigheter) etter behov.
  • Bør ha god kommunikasjons- og teamkompetanse som SDET-roller i disse dager krever kommunikasjon og samarbeid på forskjellige nivåer med flere interessenter.
  • Bør ha en grunnleggende forståelse av forskjellige systemdesignkonsepter, skalerbarhet, samtidighet, ikke-funksjonelle krav osv.

I avsnittene nedenfor vil vi prøve å forstå det generelle formatet på intervjuet sammen med noen eksempler på spørsmål.

Format av programvareutviklingsingeniør i testintervju

De fleste av selskapene har sitt foretrukne format for å intervjue kandidater for en SDET-rolle som til tider, rollen er superspesifikk for et team, og personen forventes å bli vurdert som en perfekt passform for teamet personen blir ansatt til.

Men temaet for intervjuene er generelt basert på punktene nedenfor:

  • Telefonisk diskusjon: Samtale med leder og / eller teammedlemmer som vanligvis er en screeningrunde.
  • Skriftlig runde: Med testing / test casing spesifikke spørsmål.
  • Kodningsferdighetsrunde: Enkle kodingsspørsmål (språkagnostiker) og kandidaten blir bedt om å skrive produksjonsnivåkode.
  • Forståelse av grunnleggende utviklingskonsepter: Som OOPS Concepts, SOLID Principles, etc.
  • Test Automation Framework design og utvikling
  • Skriptspråk: Selen, Python, Javascript osv
  • Culture Fit / HR diskusjon og forhandlinger

SDET intervju spørsmål og svar

I denne delen vil vi diskutere noen eksempler på spørsmål sammen med detaljerte svar, for forskjellige kategorier som blir spurt av de fleste produktselskaper som ansetter for SDET-roller.

Kodningsferdigheter

I denne runden gis enkle kodingsproblemer for å skrive på det valgte språket. Her ønsker intervjueren å måle ferdighetene med kodingskonstruksjoner, samt håndtere ting som kantscenarier og nullkontroller osv.

Noen ganger kan intervjuere også be om å skrive ned enhetstester for programmet som er skrevet.

La oss se noen eksempler på problemer.

Q # 1) Skriv et program for å bytte 2 tall uten å bruke den tredje (midlertidige) variabelen?

Svar :

Program for å bytte to tall:

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 utdataene fra kodebiten ovenfor:

output-swap2nos 8 nye 1

I kodebiten ovenfor er det viktig å merke seg at intervjueren har spesifikt bedt om å bytte 2 nr uten å bruke en tredje midlertidig variabel. Det er også viktig at før du sender løsningen, anbefales det alltid å gå gjennom (eller tørrkøre) koden for minst 2-3 innganger. La oss prøve å få positive og negative verdier.

Positive verdier: 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 verdier: 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 å reversere et tall?

Svar: Nå kan problemstillingen i utgangspunktet se skremmende ut, men det er alltid lurt å be om å avklare spørsmål til intervjueren (men ikke mange detaljer). Intervjuer kan velge å gi tips om problemet, men hvis kandidaten stiller mange spørsmål, peker det også på at kandidaten ikke gir nok tid til å forstå problemet godt.

Her forventer problemet at en kandidat også kommer med noen antakelser - for eksempel, tallet kan være et helt tall. Hvis inngangen er 345, skal utgangen være 543 (som er omvendt av 345)

La oss se kodebiten for denne løsningen:

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 programmet mot input : 10025 - Forventet ville være : 52001

output-reverseNumber 6 new

Q # 3) Skriv et program for å beregne et talls faktor?

Svar: Faktor er et av de vanligste spørsmålene i nesten alle intervjuer (inkludert utviklerintervjuene)
For utviklerintervjuer er det mer fokus på programmeringskonsepter som dynamisk programmering, rekursjon, etc, mens det fra Software Development Engineer i testperspektiv er viktig å håndtere kantscenariene som maksverdier, minverdier, negative verdier osv. Og tilnærming / effektivitet er viktige, men blir sekundære.

La oss se et program for faktoriell bruk av rekursjon og for-loop med håndtering av negative tall og retur av en fast verdi på si -9999 for negative tall som skal håndteres i programmet som kaller faktorfunksjonen.
Se kodebiten nedenfor:

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); } }

La oss se utdata for - faktoriell bruk av sløyfen, faktoriell bruk av rekursjon og faktoriell av et negativt tall (som vil gi en standard satt verdi på -9999)

output-factorial 4 nye

Q # 4) Skriv et program for å sjekke om en gitt streng har balanserte parenteser?

Svar:

Nærme seg - Dette er et litt komplekst problem, der intervjueren ser litt mer ut enn kunnskap om bare kodingskonstruksjoner. Her er forventningen å tenke og bruke den apt datastrukturen for det aktuelle problemet.

Mange av dere kan føle seg skremt av denne typen problemer, ettersom noen av dere kanskje ikke har hørt disse, og selv om de er enkle, kan de høres komplekse ut.

Men generelt for slike problemer / spørsmål: For eksempel i det aktuelle spørsmålet, hvis du ikke vet hva balanserte parenteser er, kan du veldig godt spørre intervjueren og deretter jobbe mot løsningen i stedet for å treffe en blind flekk.

La oss se hvordan vi nærmer oss en løsning: Etter å ha forstått hva balanserte parenteser er, kan du tenke på å bruke riktig datastruktur og deretter begynne å skrive algoritmer (trinn) før du begynner å kode løsningen. Mange ganger løser algoritmene i seg selv mange kantscenarier og gir mye klarhet i hvordan løsningen vil se ut.

La oss se på løsningen:

Balanserte parenteser er å sjekke for en gitt streng som inneholder parenteser (eller parenteser), og skal ha like mange åpninger og lukkinger, så vel som posisjonert godt strukturert. For konteksten av dette problemet vil vi bruke balanserte parenteser som - ‘()’, ‘()’, ‘{}’ - dvs. streng kan ha en hvilken som helst kombinasjon av disse parentesene.

Vær oppmerksom på at før du prøver problemet, er det greit å avklare om strengen bare inneholder parentestegn eller tall osv. (Da dette kan endre logikken litt)

Eksempel: En gitt streng - '{() {} ()} - er en balansert streng da den er strukturert og har like stort antall lukkende og åpne parenteser, men streng -' {(}) {} () '- denne strengen - selv om har like mange åpnings- og lukkeparenteser, dette er fremdeles ikke balansert fordi du kan se at uten lukking '(' vi har lukket '}' (dvs. alle indre parenteser bør lukkes før du lukker en ytre parentes)

Vi vil bruke en stabeldatastruktur for å løse dette problemet. Hvis du vil vite mer om grunnleggende om stakk, kan du se her

En bunke er en LIFO (Last In First Out type datastruktur), tenk på den som en bunke / haug med tallerkener i et bryllup - du vil plukke opp den øverste tallerkenen når du bruker den.

Algoritme:

#1) Erklære en tegnstabel (som vil holde tegnene i strengen, og avhengig av logikk, trykk og popp tegnene ut).

# 2) Gå gjennom inngangsstrengen, og når som helst

  • Det er et åpningsbraketttegn - dvs. '(', {'eller' ('- skyv tegnet på Stack.
  • Det er et lukkende tegn - dvs. ')', '}', ')' - pop et element fra Stack og sjekk om det samsvarer med det motsatte av lukkende tegn - dvs. hvis tegnet er '}' så kan du forvente på Stack pop {'
    • Hvis det poppede elementet ikke stemmer overens med de avsluttende parentesene, er ikke strengen balansert, og du kan returnere resultater.
    • Ellers fortsett med stack push og pop-tilnærmingen (gå til trinn 2).
  • Hvis strengen krysses helt og stakkstørrelsen også er null, kan vi si / slutte at den gitte strengen er en balansert parentesstreng.

På dette punktet vil du kanskje også diskutere løsningsmetoden du har som algoritme og sørge for at intervjueren er ok med tilnærmingen.

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

Resultatet av kodebiten ovenfor:

output-balancedParantheses 2 nye

Som vi gjorde for våre tidligere kodingsproblemer, er det alltid bra å tørre kjøre koden med minst 1-2 gyldige så vel som 1-2 ugyldige innganger og sørge for at alle saker blir håndtert riktig.

MERK: Det er alltid godt å tenke løsningen høyt (og ikke bare i tankene) - og overraskende er dette et viktig trekk som intervjuere leter etter. Mange intervjuere kan bare fjerne algoritmen og gå til neste problemstilling.

I den ovennevnte kodingsløsningen, for utviklerintervjuet, kan intervjueren be om å løse det ved hjelp av arrays i stedet for direkte stack (dvs. bruke array som en stack), men generelt handler det mer om å være konseptuelt tydelig og i stand til å håndtere alle gyldige og ugyldige innganger.

Test Automation Framework Related

Denne delen av intervjuet er mer spesifikk rundt testing og SDET-ansvar. Forvent automatiseringsrammeverkdesign og utviklingsrelaterte spørsmål, fordeler og ulemper ved å bruke forskjellige tilnærminger osv.

La oss se noen eksempler på spørsmål og løsninger for det samme.

Q # 5) Forklare og designe komponenter i automatiseringsrammeverket for en webapplikasjon?

Svar: Dette spørsmålet er litt subjektivt, og intervjueren har til hensikt å måle hvor mye kandidaten vet om rammedesign og utvikling. Svaret på dette spørsmålet hjelper intervjueren å forstå om kandidaten kan bygge eller lage tilpassede rammer fra bunnen av.
La oss se et par punkter som kan hjelpe deg med å strukturere løsningen på dette spørsmålet:

  • Du kan snakke om forskjellige typer rammer som - Datadrevet, Keyword-driven, Hybrid Framework.
  • Sideobjektmodell for lagring av detaljer om forskjellige elementer på forskjellige sider / moduler i webapplikasjonen.
  • Vanlige moduler som hjelperfunksjoner, verktøy, loggere osv.
  • Rapporteringsmoduler som generering av rapporter om testutførelse, integrering av rapporter med e-post og planlegging av testutførelse, etc.

Anbefalt lesing => Mest populære testautomatiseringsrammer

Q # 6) Forklar teststrategier for en mobilapplikasjon?

Svar: Disse spørsmålene blir vanligvis stilt avhengig av hvilken rolle. Hvis rollen hovedsakelig er å jobbe med mobilapper, har spørsmålet mer relevans. Du kan snakke fra din erfaring hvis du har planlagt mobiltesting som en del av din nåværende eller tidligere rolle.

Noen tips for å strukturere svaret på dette spørsmålet kan være,

  • Testing på enheter vs emulatorer.
  • Identifisere og lagre objekter / elementer på forskjellige skjermer - Eksempel: Sideobjektmodell.
  • Lastetesting av en mobilapplikasjon.
  • Du kan snakke om forskjellige typer mobilapplikasjoner som - Native apps, Hybrid apps, og diskutere strategier / tilnærminger du vil bruke til å teste dem.

Anbefalt lesing => Tutorials for testing av mobilapper

Q # 7) Designe et automatiseringsrammeverk for testing av REST APIer?

Svar: Dette er igjen et subjektivt spørsmål, og du kan stille avklarende spørsmål om intervjueren vil at du skal utvikle et rammeverk for testing av funksjonell oppførsel av API eller ikke-funksjonelle krav som Load / Performance testing.

Du kan starte svaret som dekker punktene nedenfor:

  • API Automation-rammekomponenter som lokalt oppsett, Mock-oppsett av API eller Hosted API-testing.
  • Verktøy som brukes til API-automatisering. Det finnes forskjellige verktøy tilgjengelig for å validere funksjonelle aspekter av et REST-basert API. Noen slike verktøy er Postman, Rest Assured, etc. For detaljerte detaljer om forskjellige verktøy kan du se artikkelen vår her .
  • Ikke-funksjonell automatisering av API-ene.
  • Planlagt gjennomføring av automatiseringstester.
  • Integrering av automatiseringstester for APIer.

Q # 8) Rammespesifikke spørsmål.

Svar: Noen ganger avhengig av profilen som blir intervjuet, kan det være krav om at en kandidat skal være dyktig med et visst rammeverk - f.eks. Selen, JMeter, etc.

Anbefalt lesing => Postbud , Mockito , Specflow , Selen , JMeter

Testrelatert

Selv om det sjelden, men avhengig av profilen, kan det være spørsmål rundt generell testpraksis, vilkår og teknologier - som alvorlighetsgrad, prioritet, testplanlegging, testkabinett osv. En SDET forventes å kunne alle manuelle testkonsepter og bør være kjent med de viktige terminologiene.

I denne delen kan du forvente spørsmål som disse:

Sp # 9) Hva er de forskjellige komponentene i en testplan?

Svar: Disse blir generelt bedt om å validere de grunnleggende testkonseptene og tankegangen. Disse vilkårene og dokumentene er noe som hver manuelle kvalitetssikring så vel som automatiserings-SDET-er bør vite.
Du kan diskutere ulike komponenter i testplanen her som,

  • Inn- og utgangskriterier
  • Omfang: Diskuter testfunksjonene som er innenfor omfanget og hva alt vil bli automatisert - vil det bare være funksjonelle funksjoner eller ikke-funksjonelle krav som skalerbarhet, ytelse osv.
  • Tidslinjer
  • Verktøy som skal brukes
  • Ressurstildeling osv

Anbefalt lesing => Hvordan skrive en god testplan

Sp # 10) Hva definerer og avgjør en feils prioritet og alvorlighetsgrad?

Svar: Defektprioritet og alvorlighetsgrad kan enkelt forklares ved hjelp av eksempler. Anta at en funksjon som registrering er ødelagt og hindrer brukere i å få tilgang til applikasjonen - så er det et høyt prioritets- og alvorlighetsproblem. Tilsvarende kan det være eksempler på mangler med lav alvorlighetsgrad / høy prioritet og forskjellige andre kombinasjoner.

Generelt,

  • Prioritet betyr betydningen av problemet.
  • Alvorlighetsgrad betyr hvilken innvirkning problemet har på kunden eller brukeren av applikasjonen.

Anbefalt lesing => Defektprioritet og alvorlighetsgrad

Sp # 11) Hva er ekvivalenspartisjonering? Illustrer med et eksempel.

Svar: Equivalence Partitioning er en teknikk som hovedsakelig brukes til Black Box-testing, for å teste forskjellige kombinasjoner av innganger mot et gitt felt.

For eksempel, hvis du tester en handelsapplikasjon, og du vil skrive alle testscenarier for 'Mengde' -feltet - hva ville de forskjellige inngangene du ville teste for dette feltet?
Gitt at funksjonskravet er at antall skal være et positivt heltall mellom 1 og 100000. Så for å teste forskjellige innganger (både gyldige og ugyldige), kan du ha tester for 1 inngang fra hver slik kategori.

  • Gyldige verdier: Mellom 1 og 100000 -> test for en hvilken som helst gyldig verdi x slik at x> 1 og x<100000.
  • Grenseverdier: Test for tillatte grenseverdier, dvs. 1 og 100000.
  • Ugyldige verdier: Verdier som ligger utenfor det tillatte området - dvs. test for en slik verdi for x, slik at x 100000.

Anbefalt lesing => Ekvivalens Partisjoneringsstrategi

Systemdesign relatert

Systemdesignspørsmål er vanligvis mer egnet for utviklerintervjuer der en utvikler vurderes ut fra en bred forståelse av forskjellige generelle konsepter - som skalerbarhet, tilgjengelighet, feiltoleranse, databasevalg, threading, etc. I et nøtteskall må du bruke hele erfaring og systemkunnskap for å svare på slike spørsmål.

Men du føler kanskje at et system som tar mange års erfaring og hundrevis av utviklere å kode, hvordan kan en person svare på spørsmålet på rundt 45 minutter?

Svaret er: Her er forventningen å bedømme kandidatens forståelse og det brede kunnskapsspekteret som han eller hun kan bruke mens de løser komplekse problemer.

I dag begynner også disse spørsmålene å bli kastet i SDET-intervjuer. Her forblir forventningen den samme som for utviklerintervjuet, men med avslappede vurderingskriterier og det er for det meste en barraiser-runde, avhengig av kandidatens svar, kan en kandidat vurderes til neste nivå eller flyttes til et lavere nivå.

Generelt, for spørsmål om systemdesignintervjuer, bør kandidaten være kjent med begrepene nedenfor

  1. Grunnleggende om operativsystemer: Personsøk, filsystemer, virtuelt minne og fysisk minne osv.
  2. Nettverkskonsepter: HTTP-kommunikasjon, TCP / IP-stack, nettverkstopologier.
  3. Skalerbarhetskonsepter: Horisontal og vertikal skalering.
  4. Samtidighet / gjengekonsepter
  5. Databasetyper: SQL / Ingen SQL-databaser, når du skal bruke hvilken type database, fordeler og ulemper ved forskjellige typer databaser.
  6. Hashing teknikker
  7. Grunnleggende forståelse av LOKK setning, skjæring, partisjonering, etc.

La oss se noen eksempler på spørsmål

Q # 12) Design et URL-forkortingssystem som et liten URL ?

Svar: Mange kandidater kan ikke engang vite om URL-forkortingssystemer generelt. I så fall er det greit å spørre intervjueren om problemstillingen i stedet for å dykke ned uten forståelse.

Før du selv svarer på slike spørsmål, bør kandidatene strukturere løsningen og skrive punkter og deretter begynne å diskutere løsningen med intervjueren.

La oss diskutere løsningen kort

a) Avklare funksjonelle og ikke-funksjonelle krav

Funksjonelle krav: Funksjonskrav er rett og slett fra kundens perspektiv, det er et system som mates med en stor URL (lang lengde), og utdataene skal være en forkortet URL.

Når du får tilgang til den forkortede URL-en, bør den omdirigere brukeren til den opprinnelige URL-en. For eksempel - prøv å forkorte en faktisk URL på https://tinyurl.com/ nettside, mate en input URL som www.softwaretestinghelp.com, og du bør få en liten URL som https://tinyurl.com/shclcqa

Ikke-funksjonelle krav: Systemet skal være performant når det gjelder omdirigering med millisekunders ventetid (som et ekstra hopp for en bruker som får tilgang til den opprinnelige URL-en).

  • Forkortede nettadresser skal ha en konfigurerbar utløpstid.
  • Forkortede nettadresser skal ikke være forutsigbare.

b) Kapasitet / trafikkestimering

Dette er veldig viktig sett fra alle spørsmål om systemdesign. Kapasitetsestimering er i hovedsak å bestemme den forventede belastningen som systemet skal få. Det er alltid bra å starte med en antagelse, og diskutere med intervjueren. Dette er også viktig med tanke på planlegging av databasestørrelse, enten systemet er lese- eller skrive tungt osv.

La oss gjøre noen kapasitetstall for eksempel på URL-forkortelse.

Anta at det vil være 100 000 nye URL-forkortingsforespørsler per dag (med 100: 1 lese / skrive-forhold - dvs. for hver 1 forkortede URL vil vi ha 100 leseforespørsler mot den forkortede URL-en)

Så vi får,

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

c) Hensyn til lagring og minne

Etter kapasitetstallene kan vi ekstrapolere disse tallene for å få,

  • Lagringskapasiteten som kreves for å imøtekomme forventet belastning, For eksempel, vi kan planlegge å utforme en lagringsløsning for å støtte forespørslene i opptil 1 år.
    Eksempel: Hvis hver forkortede URL bruker 50 byte, vil total data / lagring som vi trenger i løpet av ett år være:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
  • Hensynshensyn er viktige for å planlegge systemet fra leserens perspektiv. dvs. for systemer som er lese-tunge - som den vi prøver å bygge (fordi URL-en ville blitt opprettet en gang men tilgang til flere ganger).
    Les tunge systemer bruker vanligvis hurtigbufring for å bli mer effektiv og unngå å lese fra den permanente lagringen for å spare på lese-I / U.

La oss anta at vi vil lagre 60% av våre leseforespørsler i cachen, så i løpet av året vil vi kreve 60% av totalt antall lesinger over år x byte som kreves av hver oppføring

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

Så i henhold til kapasitetstallene våre, vil dette systemet kreve omtrent 1 GB fysisk minne

d) Anslag for båndbredde

Estimater for båndbredde er nødvendige for å analysere lese- og skrivehastigheten i byte som kreves for at et system skal utføres. La oss gjøre estimater mot kapasitetstallene vi har tatt.

Eksempel: Hvis hver forkortede URL bruker 50 byte, vil de totale lese- og skrivehastighetene vi trenger 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 egentlig den viktigste forretningslogikken eller algoritmen som vil bli brukt til å oppfylle funksjonelle krav. I dette tilfellet ønsker vi å generere unike forkortede URL-er for en gitt URL.

De forskjellige tilnærmingene som kan brukes til å generere forkortede nettadresser er:

Hashing: Vi kan tenke oss å generere forkortede URL-er ved å opprette en hash av den angitte URL-en og tildele hash-nøkkelen som den forkortede URL-en.

Hashing

Denne tilnærmingen kan ha noen problemer når det er forskjellige brukere av tjenesten, og hvis de skriver inn samme URL, vil de resultere i å få samme forkortede URL.

Forhåndsopprettede forkortede strengerog tilordnes URL-er når tjenesten kalles: En annen tilnærming kan være å returnere en forhåndsdefinert forkortet streng fra bassenget med allerede genererte strenger.

Forhåndsopprettede forkortede strenger

Tjeneste-APIer: Vi kan tenke på URL-forkortelsessystemet som et sett med REST-baserte APIer som har følgende sluttpunkter:

  • createUrl (String url, DateTime expiryTime): Dette endepunktet oppretter og returnerer en forkortet URL med utløpsvarighet som angitt i inngangen.
  • retrieveUrl (streng forkortetUrl): Dette endepunktet henter URL som skal omdirigeres mot den gitte forkortede URLen.

f) Skalering og samtidighet

Skalering er et viktig hensyn fra et ikke-funksjonelt kravperspektiv.

Det tar for seg, hvordan kan systemet

  • Skala under belastning: Systemet skal være i stand til å skalere under belastning og ikke bare slutte å virke etter at en uventet økning i last oppstår.

Anbefalt lesing => Skaleringsteknikker

  • Hvor effektiv kan systemet være, for eksempel: Hvis systemet brukes med langvarig kapasitet i lang tid, ville systemets ytelse forringes eller forbli det stabilt?

Det kan være mange forskjellige spørsmål om systemdesign som nedenfor, men generelt sett vil alle disse teste kandidatens bredere forståelse av forskjellige konsepter som vi har diskutert i løsningen på URL-forkortingssystemet.

Q # 13) Design en videoplattform som Youtube.

Svar: Dette spørsmålet kan også tilnærmes, på en lignende måte som vi har diskutert TinyUrl-spørsmålet ovenfor (og dette gjelder nesten alle spørsmål om systemdesignintervju). Den eneste differensierende faktoren vil være å se / detaljere rundt systemet du vil designe.

Så for Youtube vet vi alle at det er en applikasjon for videostreaming og har mange muligheter som å la brukeren laste opp nye videoer, streame live webcasts osv. Så mens du designer systemet, bør du bruke de nødvendige systemdesignkomponentene. I dette tilfellet må vi kanskje legge til komponenter relatert til videostreaming.

Du kan diskutere punkter som,

  • Oppbevaring: Hva slags database vil du velge å lagre videoinnhold, brukerprofiler, spillelister osv.?
  • Sikkerhet og autentisering / autorisasjon
  • Bufring: Siden en streamingplattform som youtube skal være performant, er caching en viktig faktor for utforming av et slikt system.
  • Samtidighet: Hvor mange brukere kan streame video parallelt?
  • Andre plattformfunksjonaliteter som videoanbefalingstjeneste som anbefaler / foreslår brukere de neste videoene de kan se osv.

Q # 14) Design et effektivt system for å betjene 6 heiser og sørg for at en person må vente i min tid mens den venter på at heisen skal komme ?

Svar: Disse typene systemdesignspørsmål er på et lavere nivå og forventer at kandidaten først tenker gjennom heisesystemet og lister opp alle mulige funksjoner som må støttes og designer / oppretter klasser og DB-relasjoner / skjemaer som løsningen.

Fra SDET-perspektivet, ville intervjueren bare forvente hovedklassene du tror applikasjonen eller systemet ditt ville ha, og de grunnleggende funksjonene ville bli håndtert med den foreslåtte løsningen.

La oss se forskjellige funksjoner i heisesystemet som forventes

Du kan stille avklarende spørsmål som

  • Hvor mange etasjer er det?
  • Hvor mange heiser er det?
  • Er alle heiser service / passasjerheiser?
  • Er alle heiser konfigurert til å stoppes i hver etasje?

Her er de forskjellige brukssakene som gjelder for et enkelt heisesystem:

system-design-heis_system

Når det gjelder kjerneklasser / objekter i dette systemet, kan du vurdere å ha:

  • Bruker: Behandler alle egenskapene til en bruker og handlinger de kan utføre på Heisobjekt.
  • Heis: Heis Spesifikke egenskaper som høyde, bredde, heis_serienummer.
  • Heisdør: Alt som er relatert til døren, som ingen dører, type dør, automatisk eller manuell, etc.
  • Heis_Knapp_Kontroll: Ulike knapper / kontroller tilgjengelig i heisen og forskjellige tilstander som disse kontrollene kan være i.

Når du er ferdig med å designe klasser og deres forhold, kan du snakke om å konfigurere DB-skjemaer.

En annen viktig komponent i heis-systemet er Eventing System. Du kan snakke om implementering av køer eller i et mer komplekst oppsett for å lage hendelsesstrømmer ved hjelp av Apache Kafka der hendelsene blir levert til de respektive systemene du skal reagere på.

Eventing System er et viktig aspekt ettersom det er flere brukere (i forskjellige etasjer) som bruker heisen samtidig. Derfor bør brukerens forespørsler bli satt i kø og servert i henhold til den konfigurerte logikken i heisekontrollerne.

Q # 15) Design Instagram / Twitter / Facebook.

Svar: Alle disse plattformene er på en måte relatert siden de lar brukerne være koblet på en eller annen måte og dele ting via forskjellige mediatyper - som meldinger / videoer og chatter også.

Så for disse typer applikasjoner / plattformer for sosiale medier, bør du ta med punktene nedenfor mens du diskuterer utforming av slike systemer (i tillegg til det vi har diskutert for utforming av URL-forkortingssystem):

  • Kapasitetsestimering: De fleste av disse systemene vil være lese-tunge, derfor er kapasitetsestimering nødvendig og vil gjøre det mulig for oss å sikre at riktig server- og databasekonfigurasjon er sikret for å betjene den nødvendige belastningen.
  • DB-ordning: De viktigste viktige DB-skjemaene som skal diskuteres er - Brukerdetaljer, Brukerforhold, Meldingsskjemaer, Innholdsskjemaer.
  • Video- og bildebehandlingsservere: De fleste av disse applikasjonene har videoer og bilder som deles på tvers av brukere. Derfor bør Video- og Image Hosting-serverne konfigureres etter behov.
  • Sikkerhet: Alle disse appene bør sikre et høyt sikkerhetsnivå på grunn av brukerinformasjonen / personlig identifiserbar informasjon om brukerne de lagrer. Ethvert forsøk på hacking, SQL Injection, bør ikke lykkes på disse plattformene, da det kan koste å miste data fra millioner av kunder.

Scenariobaserte problemer

Scenariobaserte problemer er generelt for eldre mennesker, der forskjellige sanntidsscenarier blir gitt, og kandidaten blir spurt om hvordan de vil håndtere en slik situasjon.

Spørsmål nr. 16) Gitt at en kritisk hurtigreparasjon må frigis så snart som mulig - Hva slags teststrategi vil du ha?

Svar: Nå, her vil intervjueren egentlig forstå

  • Hvordan og hva slags teststrategier du kan tenke deg?
  • Hvilken dekning vil du gjøre for hurtigreparasjonen?
  • Hvordan vil du validere hurtigreparasjonen etter distribusjonen? etc.

For å svare på slike spørsmål, du kan bruke virkelige situasjoner hvis du kan forholde deg til problemet. Du bør også nevne at uten hensiktsmessig testing ville du ikke være villig til å gi ut noen kode til produksjonen.

For de kritiske løsningene, bør du alltid jobbe sammen med utvikleren og prøve å forstå hvilke områder det kan påvirke og forberede et miljø som ikke er i produksjon for å replikere scenariet og teste løsningen.

Det er også viktig her å nevne at du vil fortsette å overvåke reparasjonen (ved hjelp av overvåkingsverktøy, dashbord, logger osv.) Etter distribusjon for å se unormal oppførsel i produksjonsmiljøet og sikre at det ikke er noen negativ innvirkning på løsningen som er ferdig.

Det kan også være andre spørsmål som hovedsakelig er å forstå kandidatens perspektiv på automatiseringstesting, leveringstidslinjer osv. (Og disse spørsmålene kan variere fra selskap til selskap så vel som ansiennitet i rollen. Vanligvis blir disse spørsmålene stilt for senior- / ledernivå roller)

Spørsmål nr. 17) Vil du ofre full testing for å frigjøre et produkt raskt?

Svar: Disse spørsmålene involverer vanligvis intervjueren til å forstå tankene dine fra et lederskapsperspektiv og hva er det du vil gå på akkord med, og vil du være villig til å frigjøre et buggyprodukt i stedet for kortere tid.

Svarene på disse spørsmålene bør underbygges mot kandidatens faktiske erfaringer.

For eksempel, du kan nevne at tidligere måtte du ringe for å frigjøre noen hurtigreparasjoner, men det kunne ikke testes på grunn av manglende tilgjengelighet av integrasjonsmiljøet. Så du ga det ut på en kontrollert måte - ved å rulle ut til en mindre prosentandel og deretter overvåket logger / hendelser og deretter startet full utrulling, etc.

Spørsmål nr. 18) Hvordan vil du lage automatiseringsstrategi for et produkt som ikke har noen automatiseringstester i det hele tatt?

Svar: Disse spørsmålene er åpne og er generelt et godt sted å ta diskusjonen slik du vil. Du kan også vise frem dine ferdigheter, kunnskaper og teknologiområder som er din styrke.

For eksempel, for å svare på disse spørsmålstypene kan du sitere eksempler på automatiseringsstrategi du brukte mens du bygde et produkt i din tidligere rolle.

For eksempel kan du nevne punkter som,

  • Siden produktet krevde å starte automatisering fra bunnen av, fikk du nok tid til å tenke og designe for et passende automatiseringsrammeverk som valgte et språk / teknologi som de fleste hadde kunnskapen til å unngå å introdusere et nytt verktøy og utnytte eksisterende kunnskap.
  • Du startet med å automatisere de mest grunnleggende funksjonelle scenariene som ble ansett for å være P1 (uten hvilken ingen utgivelse kunne gå gjennom).
  • Du tenkte også på å teste ytelse og skalerbarhet av systemet gjennom automatiserte testverktøy som JMETER, LoadRunner, etc.
  • Du tenkte på å automatisere sikkerhetsaspektene ved applikasjonen som er oppført i OWASP Sikkerhetsstandarder.
  • Du integrerte de automatiserte testene i bygningsrørledningen for tidlig tilbakemelding etc.

Team Fit & Culture Fit

Denne runden avhenger vanligvis av selskap til selskap. Men behovet / nødvendigheten av denne runden er å forstå kandidaten fra perspektivet til team- og organisasjonskulturperspektiv. Hensikten med disse spørsmålene er også å forstå kandidatens personlighet og deres tilnærming til arbeid / mennesker etc.

Generelt er HR- og ansettelsesledere de som gjennomfører denne runden.

Spørsmål som vanligvis dukker opp i løpet av denne runden er som:

Spørsmål nr. 19) Hvordan løser du konflikter innenfor din nåværende rolle?

Svar: Ytterligere forklaring her er: antar at du har en konflikt med sjefen din eller nærmeste teammedlemmer, hva er trinnene du tar for å løse disse konfliktene?

For denne typen spørsmål underbygger du så mye du kan med virkelige eksempler som kan ha skjedd i karrieren din i nåværende eller tidligere organisasjoner.

Du kan nevne ting som:

  • Du liker å sortere ut eventuelle konflikter så snart som mulig som oppstår på grunn av profesjonelle årsaker (og vil ikke påvirke dine personlige forhold på grunn av disse).
  • Du kan nevne at du generelt prøver å kommunisere effektivt og snakke / diskutere med personen individuelt for å løse eventuelle forskjeller / problemer.
  • Du kan nevne at hvis ting begynner å bli verre, vil du ta hjelp av en eldre person / lederen din og få hans / hennes innspill.

Andre eksempler på team fit / culture fit spørsmål er nedenfor (de fleste av dem bør besvares i en lignende tilnærming vi diskuterte for spørsmålet ovenfor. Å snakke om virkelige scenarier er en nøkkel her, da intervjueren kan fortelle det på en bedre måte som vi vil.

Spørsmål nr. 20) Hva slags balanse mellom arbeid og privatliv forventer du av den nye rollen du blir ansett for?

Svar: Siden Hiring Manager er noen som vet hva rollen krever, hvor mye ekstra innsats kan det være nødvendig til tider, så generelt prøver intervjueren å måle om forventningene dine er radikalt forskjellige fra det rollen forventer.

Anta at du sier at du ikke foretrekker å delta på nattmøter og rollen forventer at du har et stort samarbeid mellom et team som sitter i en annen tidssone, så kan intervjueren starte en diskusjon om at dette er forventningene fra rollen - Vil du være i stand til å tilpasse? etc.

Så igjen, dette er mer en uformell samtale, men fra intervjuerens perspektiv ønsker de å forstå forventningene dine til å evaluere kandidaturet ditt for stillingen du blir intervjuet for.

Q # 21) Hva er dine hobbyer, bortsett fra jobb?

Svar: Disse spørsmålene er rent subjektive og individuelle, og disse spørsmålene er generelt nyttige for å få kandidaten til å føle seg avslappet og lett og innlede uformelle diskusjoner.

Generelt kan svarene på disse spørsmålene være som - du liker å lese en bestemt sjanger, du liker musikk, du mottok noen pris for noen frivillig / filantropiaktivitet osv. Disse spørsmålene blir generelt sett stilt i HR-runden (og mindre sannsynlig å bli spurt av en teknisk person).

Spørsmål nr. 22) Hvor mye tid er du villig til å bruke læring på nye verktøy og teknologier proaktivt?

Svar: Her måler intervjueren din vilje til å lære nye ting hvis noe uvanlig eller nytt blir kastet mot deg. Det lar også intervjueren vite at du er proaktiv? Er du villig til å investere i deg selv og din karriere? etc.

Så mens du svarer på slike spørsmål - vær ærlig og begrunn svarene dine med eksempler - For eksempel, Du kan nevne at du møtte opp for en Java-sertifisering i fjor og forberedte deg utenfor arbeidet ved å ta noen timer hver uke.

Konklusjon

I denne artikkelen diskuterte vi Software Development Engineer i intervjuprosessen og eksempler på spørsmål som vanligvis blir stilt fra kandidatene på tvers av forskjellige organisasjoner og profiler. Generelt er SDET-intervjuer veldig brede og er veldig avhengige av selskap til selskap.

Men intervjuprosessene ligner på det som finnes for en utviklerprofil med større vekt på kvalitet og automatiseringsrammer.

Det er viktig å forstå at i dag er selskaper mindre fokusert på noe spesifikt språk eller teknologi, men mer om en bred forståelse av konsepter og evnen til å tilpasse seg verktøyene / teknologiene som kreves av selskapet.

Beste ønsker for ditt SDET-intervju!

Anbefalt lesing

^