sdet interview questions
Läs den här fullständiga guiden till Software Development Engineer i testintervjuer för att veta formatet och hur du svarar på SDET-intervjufrågor som ställts i de olika omgångarna:
I den här handledningen lär vi oss några vanliga intervjufrågor för SDET-rollerna. Vi kommer också att se generellt det gemensamma mönstret för intervjuerna och dela några tips för att utmärka sig i intervjuerna.
Vi kommer att använda Java-språket för kodningsproblemen för den här självstudien, men de flesta SDET-självstudierna är språkagnostiska och intervjuarna är i allmänhet flexibla kring det språk som kandidaten väljer att använda.
Vad du kommer att lära dig:
SDET Intervju Förberedelseguide
SDET-intervjuer, i de flesta av de bästa produktföretagen, liknar ganska intervjuerna för utvecklingsroller. Detta beror på att SDETs också förväntas kunna och förstå i stort sett nästan allt som utvecklaren vet.
Vad som skiljer sig från är kriterierna som SDET-intervjuaren bedömer. Intervjuare för denna roll letar efter kritiska tänkande färdigheter, liksom om personen som intervjuas har praktisk erfarenhet av kodning och har ett öga för kvalitet och detaljer.
Här är några punkter som någon som förbereder sig för en SDET-intervju till stor del bör fokusera på:
agil scrum metodologi intervju frågor svar
- Eftersom dessa intervjuer för det mesta är agnostiska för teknik / språk, måste kandidater därför vara villiga att lära sig ny teknik (och utnyttja befintliga färdigheter) efter behov.
- Bör ha god kommunikations- och lagkompetens eftersom SDET-roller idag kräver kommunikation och samarbete på olika nivåer med flera intressenter.
- Bör ha en grundläggande förståelse för olika systemdesignkoncept, skalbarhet, samtidighet, icke-funktionella krav etc.
I avsnitten nedan kommer vi att försöka förstå intervjuets allmänna format tillsammans med några exempelfrågor.
Format för Software Development Engineer i testintervju
De flesta av företagen har sitt föredragna format för att intervjua kandidater för en SDET-roll som ibland, rollen är superspecifik för ett team och personen förväntas utvärderas som en perfekt passform för det team som personen anställs för.
Men temat för intervjuerna bygger i allmänhet på följande punkter:
- Telefonisk diskussion: Konversation med chefen och / eller teammedlemmar som vanligtvis är en screeningrunda.
- Skriftlig omgång: Med test- / testhöljespecifika frågor.
- Kodningsfärdighetsrunda: Enkla kodfrågor (språkagnostiker) och kandidaten uppmanas att skriva produktionsnivåkod.
- Förståelse för grundläggande utvecklingskoncept: Som OOPS-koncept, SOLID-principer, etc.
- Test Automation Framework design och utveckling
- Skriptspråk: Selen, Python, Javascript, etc.
- Culture Fit / HR-diskussion och förhandlingar
SDET-intervjufrågor och svar
I det här avsnittet kommer vi att diskutera några exempelfrågor tillsammans med detaljerade svar för olika kategorier som ställs av de flesta produktföretag som anställer för SDET-roller.
Kodningsförmåga
I den här omgången ges enkla kodningsproblem för att skriva på det språk du väljer. Här vill intervjuaren mäta skickligheten med kodkonstruktioner samt hantera saker som kantscenarier och nollkontroller etc.
Ibland kan intervjuare också be att skriva ner enhetstester för det skrivna programmet.
Låt oss se några exempel på problem.
F # 1) Skriv ett program för att byta 2 nummer utan att använda den tredje (tillfälliga) variabeln?
Svar :
Program för att byta två nummer:
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); } }
Här är utdata från ovanstående kodavsnitt:
I ovanstående kodavsnitt är det viktigt att notera att intervjuaren specifikt har bett att byta 2 nr utan att använda en tredje tillfällig variabel. Det är också viktigt att innan du skickar lösningen rekommenderas det alltid att gå igenom (eller torka) koden för minst 2-3 ingångar. Låt oss försöka hitta positiva och negativa värden.
Positiva värden: 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)
Negativa värden: 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)
F # 2) Skriv ett program för att vända ett nummer?
Svar: Nu kan problemuppgiften initialt se skrämmande ut, men det är alltid klokt att ställa frågor till intervjuaren (men inte mycket detaljer). Intervjuare kan välja att ge tips om problemet, men om kandidaten ställer många frågor, pekar det också på att kandidaten inte ger tillräckligt med tid för att förstå problemet väl.
Här förväntar sig problemet att en kandidat också gör några antaganden - till exempel, siffran kan vara ett heltal. Om ingången är 345 ska utgången vara 543 (vilket är omvänd från 345)
Låt oss se kodavsnittet för den här 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; } }
Utgång för detta program mot inmatning : 10025 - Förväntat skulle vara : 52001
F # 3) Skriv ett program för att beräkna ett tals faktorn?
Svar: Faktor är en av de vanligaste frågorna i nästan alla intervjuer (inklusive utvecklarintervjuerna)
För utvecklarintervjuer är mer fokus på programmeringskoncept som dynamisk programmering, rekursion, etc, medan det från Software Development Engineer i testperspektiv är viktigt att hantera kantscenarier som maxvärden, minvärden, negativa värden etc och strategi / effektivitet är viktiga men blir sekundära.
Låt oss se ett program för faktoriell användning av rekursion och for-loop med hantering av negativa siffror och returnering av ett fast värde på säg -9999 för negativa nummer som ska hanteras i programmet som kallar faktorfunktionen.
Se kodavsnittet nedan:
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); } }
Låt oss se utdata för - faktoria med loop, faktoria med rekursion och faktoria av ett negativt tal (vilket skulle returnera ett standardinställningsvärde på -9999)
F # 4) Skriv ett program för att kontrollera om en viss sträng har balanserade parenteser?
Svar:
Närma sig - Detta är ett lite komplext problem, där intervjuaren ser lite mer än kunskap om bara kodningskonstruktioner. Här är förväntningen att tänka och använda den apt datastrukturen för det aktuella problemet.
Många av er kanske känner sig skrämda av dessa typer av problem, eftersom vissa av er kanske inte har hört dessa, och även om de är enkla kan de låta komplicerade.
Men i allmänhet för sådana problem / frågor: Till exempel i den aktuella frågan, om du inte vet vad balanserade parenteser är, kan du mycket väl fråga intervjuaren och sedan arbeta mot lösningen istället för att slå en blind fläck.
Låt oss se hur vi närmar oss en lösning: Efter att ha förstått vad balanserade parenteser är kan du tänka på att använda rätt datastruktur och sedan börja skriva algoritmer (steg) innan du börjar koda lösningen. Många gånger löser algoritmerna själva många kantscenarier och ger mycket tydlighet om hur lösningen kommer att se ut.
Låt oss titta på lösningen:
Balanserade parenteser är att söka efter en viss sträng som innehåller parenteser (eller parenteser), ska ha lika öppnings- och stängningsantal och vara väl strukturerade. I samband med detta problem kommer vi att använda balanserade parenteser som - '()', '()', '{}' - det vill säga en given sträng kan ha vilken kombination som helst av dessa parenteser.
Observera att innan du försöker problemet är det bra att klargöra om strängen bara kommer att innehålla parentes tecken eller några siffror etc (eftersom detta kan förändra logiken lite)
Exempel: En given sträng - '{() {} ()} - är en balanserad sträng eftersom den är strukturerad och har lika stort antal stängnings- och öppningsparenteser, men sträng -' {(}) {} () '- den här strängen - även om har lika många öppnings- och stängningsparenteser, detta är fortfarande inte balanserat eftersom du kan se att utan att stänga '(' vi har stängt '}' (dvs. alla inre fästen bör stängas innan du stänger en yttre fäste)
Vi kommer att använda en stapeldatastruktur för att lösa detta problem. Om du vill veta mer om grunderna för stack, se här
En stack är en LIFO (Last In First Out typ av datastruktur), tänk på den som en stapel / hög med plattor vid ett bröllop - du kommer att plocka upp den översta plattan när du använder den.
Algoritm:
# 1) Förklara en karaktärstack (som skulle innehålla tecknen i strängen och beroende på viss logik, tryck och knäpp ut tecknen).
# 2) Gå igenom inmatningssträngen och när som helst
- Det finns ett öppningsfäste - dvs. '(', {'eller' ('- tryck på karaktären på Stack.
- Det finns en avslutande karaktär - dvs. ')', '}', ')' - pop ett element från Stack och kontrollera om det matchar motsatsen till slutet tecken - dvs. om karaktären är '}' så kan du förvänta dig på Stack pop ' {'
- Om det poppade elementet inte är motsatt matchar de stängande parenteserna är strängen inte balanserad och du kan returnera resultat.
- Annars fortsätt med stack-push och pop-metoden (gå till steg 2).
- Om strängen passeras helt och stapelstorleken också är noll, kan vi säga / dra slutsatsen att den angivna strängen är en balanserad parentessträng.
Vid den här tiden kanske du också vill diskutera den lösningsmetod som du har som algoritm och se till att intervjuaren är ok med tillvägagångssättet.
Koda:
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 Utdata från ovanstående kodavsnitt:

Som vi gjorde för våra tidigare kodningsproblem är det alltid bra att torka koden med minst 1-2 giltiga samt 1-2 ogiltiga ingångar och se till att alla ärenden hanteras på rätt sätt.
NOTERA: Det är alltid bra att tänka ut lösningen högt (och inte bara i sinnet) - och överraskande är detta ett viktigt drag som intervjuare letar efter. Många intervjuare kan bara göra sig av med algoritmen och gå vidare till nästa problemuttalande.
I ovanstående kodningslösning, för utvecklarintervjun, kan intervjuaren be att lösa det med hjälp av arrays istället för direkt stack (dvs. använda array som stack), men i allmänhet handlar det mer om att vara konceptuellt tydlig och kunna hantera alla giltiga och ogiltiga ingångar.
Test Automation Framework Related
Det här avsnittet i intervjun är mer specifikt kring testning och SDET-ansvar. Förvänta dig design av automatiseringsramar och utvecklingsrelaterade frågor, fördelar och nackdelar med att använda olika metoder etc.
Låt oss se några exempel på frågor och lösningar för detsamma.
F # 5) Förklara och designa komponenter i automatiseringsramen för en webbapplikation?
Svar: Denna fråga är lite subjektiv och intervjuaren avser att mäta hur mycket kandidaten vet om ramkonstruktionen och utvecklingen. Svaret på den här frågan hjälper intervjuaren att förstå om kandidaten kan bygga eller skapa anpassade ramar från grunden.
Låt oss se några punkter som kan hjälpa dig att strukturera lösningen för den här frågan:
- Du kan prata om olika typer av ramar som - Data-driven, Keyword-driven, Hybrid Framework.
- Sidobjektmodell för att lagra information om olika element på olika sidor / moduler i webbapplikationen.
- Vanliga moduler som hjälpfunktioner, verktyg, loggare etc.
- Rapporteringsmoduler som att generera rapporter om testkörning, integrera rapporter med e-post och schemalägga testkörning etc.
Rekommenderad läsning => De mest populära testautomatiseringsramarna
F # 6) Förklara teststrategier för en mobilapplikation?
Svar: Dessa frågor ställs vanligtvis beroende på roll. Om rollen huvudsakligen är att arbeta med mobilappar har frågan mer relevans. Du kan prata från din erfarenhet om du har planerat mobiltestning som en del av dina nuvarande eller tidigare roller.
Några tips för att strukturera svaret på denna fråga kan vara,
- Testning på enheter vs emulatorer.
- Identifiera och lagra objekt / element på olika skärmar - Exempel: Sidobjektmodell.
- Lasttestning av en mobilapplikation.
- Du kan prata om olika typer av mobilapplikationer som - Inbyggda appar, hybridappar och diskutera strategier / tillvägagångssätt som du skulle använda för att testa dem.
Rekommenderad läsning => Handledning för testning av mobilappar
F # 7) Designa ett automatiseringsramverk för testning av REST API: er?
Svar: Detta är återigen en subjektiv fråga och du kan ställa klargörande frågor om intervjuaren vill att du ska utveckla en ram för att testa funktionellt beteende hos API eller icke-funktionella krav som Load / Performance-test.
Du kan börja ditt svar som täcker nedanstående punkter:
- API Automation ramkomponenter som lokal installation, Mock-installation av API eller Hosted API-testning.
- Verktyg som används för API-automatisering. Det finns olika verktyg tillgängliga för att validera de funktionella aspekterna av ett REST-baserat API. Några sådana verktyg är Postman, Rest Assured, etc. För detaljerade detaljer om olika verktyg kan du hänvisa till vår artikel här .
- Icke funktionell automatisering av API: er.
- Schemalagd körning av automatiseringstester.
- Integrera automatiseringstester för API: er.
Fråga # 8) Ramspecifika frågor.
Svar: Ibland beroende på vilken profil som intervjuas kan det finnas ett krav på att en kandidat är skicklig med ett visst ramverk - t.ex. Selen, JMeter, etc.
Rekommenderad läsning => Brevbärare , Mockito , Specflow , Selen , JMeter
Testrelaterat
Även om det sällan, men beroende på profilen, kan det finnas frågor kring allmänna testmetoder, termer och tekniker - som felgrad, prioritet, testplanering, testhölje etc. En SDET förväntas känna till alla manuella testkoncept och bör vara bekant med de viktiga terminologierna.
I det här avsnittet kan du förvänta dig frågor som dessa:
F # 9) Vilka är de olika komponenterna i en testplan?
Svar: Dessa ombeds vanligtvis att validera de grundläggande testkoncepten och tänkesättet. Dessa termer och dokument är något som varje manuell kvalitetssäkring såväl som SDET för automatisering borde veta.
Du kan diskutera olika komponenter i testplanen här som,
- Kriterier för in- och utresa
- Omfattning: Diskutera testfunktionerna som är inom räckvidden och vad allt skulle vara automatiserat - kommer det bara att vara funktionella funktioner eller icke-funktionella krav som skalbarhet, prestanda etc.
- Tidslinjer
- Verktyg som ska användas
- Resurstilldelning osv
Rekommenderad läsning => Hur man skriver en bra testplan
F # 10) Vad definierar och bestämmer en bugs prioritet och svårighetsgrad?
Svar: Defektprioritet och svårighetsgrad kan enkelt förklaras med hjälp av exempel. Antag att en funktion som att registrera dig är trasig och hindrar användare från att komma åt applikationen - då är det en hög prioritet och hög svårighetsfråga. På samma sätt kan det finnas exempel på defekter med låg svårighetsgrad / hög prioritet och olika andra kombinationer.
I allmänhet,
- Prioritet betyder betydelsen av frågan.
- Allvarlighetsgrad betyder vilken inverkan problemet har på kunden eller användaren av applikationen.
Rekommenderad läsning => Defektprioritet och svårighetsgrad
F # 11) Vad är ekvivalenspartitionering? Illustrera med ett exempel.
Svar: Equivalence Partitioning är en teknik som mest används för Black Box-testning för att testa olika kombinationer av ingångar mot ett visst fält.
Till exempel, om du testar en handelsapplikation och vill skriva alla testscenarier för fältet 'Kvantitet' - vilka olika ingångar skulle du testa för detta fält?
Med tanke på att funktionskravet är att kvantiteten ska vara ett positivt heltal mellan 1 och 100000. Så för att testa olika ingångar (både giltiga och ogiltiga) kan du testa 1 ingång från varje sådan kategori.
- Giltiga värden: Mellan 1 och 100000 -> testa för ett giltigt värde x så att x> 1 och x<100000.
- Gränsvärden: Testa de tillåtna gränsvärdena dvs 1 & 100000.
- Ogiltiga värden: Värden som ligger utanför det tillåtna intervallet - dvs testa ett sådant värde för x, så att x 100000.
Rekommenderad läsning => Equivalence Partitioning strategi
Systemdesign relaterad
Systemdesignfrågor är vanligtvis mer lämpade för utvecklarintervjuer där en utvecklare bedöms utifrån en bred förståelse för olika allmänna begrepp - som skalbarhet, tillgänglighet, feltolerans, databasval, trådning etc. I ett nötskal måste du använda hela erfarenhet och systemkunskap för att svara på sådana frågor.
Men du kanske känner att ett system som tar många års erfarenhet och hundratals utvecklare att koda, hur kan en person svara på frågan på cirka 45 minuter?
Svaret är: Här är förväntningen att bedöma kandidatens förståelse och det breda spektrum av kunskap som han eller hon kan tillämpa när man löser komplexa problem.
Numera börjar dessa frågor också kastas i SDET-intervjuer. Här förblir förväntningarna desamma som för utvecklarintervjun, men med avslappnade bedömningskriterier och det är mestadels en bar raiser-runda där en kandidat, beroende på kandidatens svar, kan övervägas till nästa nivå eller flyttas till en lägre nivå.
I allmänhet, för frågor om systemdesignintervjuer, bör kandidaten känna till begreppen nedan
- Grunderna för operativsystem: Personsökning, filsystem, virtuellt minne och fysiskt minne etc.
- Nätverkskoncept: HTTP-kommunikation, TCP / IP-stack, nätverkstopologier.
- Skalbarhetskoncept: Horisontell och vertikal skalning.
- Samtidighet / gängningskoncept
- Databastyper: SQL / Inga SQL-databaser, när ska man använda vilken typ av databas, fördelar och nackdelar med olika typer av databaser.
- Hashing tekniker
- Grundläggande förståelse för KEPS sats, skärning, partitionering etc.
Låt oss se några exempel på frågor
F # 12) Utforma ett URL-förkortningssystem som ett liten URL ?
Svar: Många kandidater kanske inte ens vet om URL-förkortningssystem i allmänhet. I så fall är det ok att fråga intervjuaren om problemförklaringen istället för att dyka ner utan förståelse.
Innan de ens svarar på sådana frågor, bör kandidaterna strukturera lösningen och skriva punkter och sedan börja diskutera lösningen med intervjuaren.
Låt oss diskutera lösningen i korthet
a) Förtydliga funktionella och icke-funktionella krav
Funktionella krav: Funktionskrav är helt enkelt ur kundens perspektiv, det är ett system som matas med en stor (lång längd) URL och utdata ska vara en förkortad URL.
När den förkortade URL: n nås bör den omdirigera användaren till den ursprungliga URL: n. Till exempel - försök att förkorta en verklig URL på https://tinyurl.com/ webbsida, mata en inmatad URL som www.softwaretestinghelp.com och du bör få en liten URL som https://tinyurl.com/shclcqa
Icke-funktionella krav: Systemet ska fungera i termer av omdirigering med millisekunders latens (eftersom det är ett extra hopp för en användare som får åtkomst till den ursprungliga URL: n).
- Förkortade webbadresser bör ha en konfigurerbar utgångstid.
- Förkortade webbadresser bör inte vara förutsägbara.
b) Kapacitet / trafikuppskattning
Detta är väldigt viktigt ur alla systemdesignfrågor. Kapacitetsberäkning bestämmer i huvudsak den förväntade belastningen som systemet kommer att få. Det är alltid bra att börja med ett antagande och diskutera med intervjuaren. Detta är också viktigt ur perspektivet för planering av databasstorlek, oavsett om systemet är läs- eller skrivtungt etc.
Låt oss göra några kapacitetsnummer för exempel på URL-förkortare.
Anta att det kommer att finnas 100 000 nya URL-förkortningar per dag (med 100: 1 läs-skrivförhållande - dvs. för varje 1 förkortad URL kommer vi att ha 100 läsförfrågningar mot den förkortade URL: n)
Så vi kommer att ha,
100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second
c) Lagrings- och minnesöverväganden
Efter kapacitetsnummer kan vi extrapolera dessa siffror för att få,
- Lagringskapaciteten som krävs för att tillgodose den förväntade belastningen, Till exempel, vi kan planera att utforma en lagringslösning för att stödja begäran i upp till ett år.
Exempel: Om varje förkortad URL förbrukar 50 byte, skulle den totala data / lagring som vi skulle behöva under ett år vara:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
- Minneshänsyn är viktiga för att planera systemet ur läsarens perspektiv. dvs för system som är lästunga - som det vi försöker bygga (eftersom URL: en skulle skapas en gång men nås flera gånger).
Läs tunga system använder i allmänhet caching för att bli mer prestanda och undvik att läsa från den permanenta lagringen för att spara på läst I / O.
Låt oss anta att vi vill lagra 60% av våra läsförfrågningar i cachen, så under året skulle vi kräva 60% av de totala läsningarna över år x byte som krävs för varje post
=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GB
Så enligt våra kapacitetsnummer skulle detta system kräva cirka 1 GB fysiskt minne
d) Uppskattningar av bandbredd
Uppskattningar av bandbredd krävs för att analysera läs- och skrivhastigheten i byte som krävs för att ett system ska kunna utföras. Låt oss göra uppskattningar mot kapacitetsnumren vi har tagit.
Exempel: Om varje förkortad webbadress förbrukar 50 byte, skulle de totala läs- och skrivhastigheterna som vi skulle behöva vara enligt nedan:
WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s
e) Systemdesign och algoritm
Detta är i huvudsak den huvudsakliga affärslogiken eller algoritmen som skulle användas för att uppfylla funktionskraven. I det här fallet vill vi skapa unika förkortade webbadresser för en viss URL.
De olika tillvägagångssätt som kan användas för att generera förkortade webbadresser är:
Hashing: Vi kan tänka oss att generera förkortade URL: er genom att skapa en hash för den inmatade URL: n och tilldela hash-nyckeln som den förkortade URL: n.

Detta tillvägagångssätt kan ha vissa problem när det finns olika användare av tjänsten, och om de anger samma webbadress skulle de resultera i att samma förkortade URL.
Förinställda förkortade strängaroch tilldelas URL: er när tjänsten anropas: En annan metod kan vara att returnera en fördefinierad förkortad sträng från poolen av redan genererade strängar.

Service-API: er: Vi kan tänka på URL-förkortningssystemet som en uppsättning REST-baserade API: er som har följande slutpunkter:
- createUrl (String Url, DateTime expiryTime): Den här slutpunkten skapar och returnerar en förkortad URL med giltighetstid som anges i ingången.
- retrieveUrl (String shortenedUrl): Den här slutpunkten hämtar URL som ska omdirigeras mot den angivna förkortade URL: n.
f) Skalning och samtidighet
Skalning är en viktig faktor från ett icke-funktionellt kravperspektiv.
Det handlar om, hur kan systemet
- Skala under belastning: Systemet ska kunna skala ut under belastning och inte bara sluta arbeta efter att en oväntad höjning av lasten inträffar.
Rekommenderad läsning => Skalningstekniker
- Hur prestanda kan systemet vara, till exempel: Om systemet används med långvarig kapacitet under lång tid, skulle då systemets prestanda försämras eller förbli det stabilt?
Det kan finnas många olika systemdesignfrågor som nedan, men generellt sett skulle alla dessa testa kandidatens bredare förståelse för olika begrepp som vi har diskuterat i lösningen på URL-förkortningssystemet.
F # 13) Designa en videoplattform som Youtube.
Svar: Denna fråga kan också tas fram, på liknande sätt som vi har diskuterat TinyUrl-frågan ovan (och detta gäller nästan alla frågor om systemdesignintervjuer). Den enskilda faktorn skulle vara att titta / detaljera kring systemet du vill utforma.
Så för Youtube vet vi alla att det är en applikation för videostreaming och har många funktioner som att låta en användare ladda upp nya videor, streama livewebbsändningar etc. Så när du utformar systemet bör du tillämpa de systemkomponenter som krävs. I det här fallet kan vi behöva lägga till komponenter relaterade till videostreamingfunktioner.
Du kan diskutera punkter som,
- Lagring: Vilken typ av databas skulle du välja att lagra videoinnehåll, användarprofiler, spellistor osv?
- Säkerhet och autentisering / auktorisering
- Cachning: Eftersom en streamingplattform som youtube borde vara performant är caching en viktig faktor för att utforma ett sådant system.
- Samtidighet: Hur många användare kan strömma video parallellt?
- Andra plattformsfunktioner som videorekommendationstjänst som rekommenderar / föreslår användare nästa videor de kan titta på etc.
F # 14) Utforma ett effektivt system för att driva 6 hissar och se till att en person måste vänta i min tid medan han väntar på att hissen ska komma ?
Svar: Dessa typer av systemdesignfrågor är mer låga och förväntar sig att kandidaten först tänker igenom hisssystemet och listar alla möjliga funktioner som behöver stödas och utformar / skapar klasser och DB-relationer / scheman som lösningen.
Ur SDET-perspektivet skulle intervjuaren bara förvänta sig de huvudklasser som du tror att din applikation eller ditt system skulle ha och de grundläggande funktionerna skulle hanteras med den föreslagna lösningen.
Låt oss se olika funktioner i hisssystemet som kan förväntas
Du kan ställa klargörande frågor som
- Hur många våningar finns det?
- Hur många hissar finns det?
- Är alla hissar service / passagerarhissar?
- Är alla hissar konfigurerade för att stoppas på varje våning?
Här är de olika användningsfall som är tillämpliga för ett enkelt hisssystem:

När det gäller kärnklasser / objekt i detta system kan du överväga att ha:
- Användare: Hanterar alla användarens egenskaper och åtgärder som de kan vidta för hissobjekt.
- Hiss: Hiss Specifika egenskaper som höjd, bredd, hiss_serienummer.
- Hissdörr: Alla saker relaterade till dörren som inga dörrar, typ av dörr, automatisk eller manuell, etc.
- Hiss_Knapp_Kontroll: Olika knappar / kontroller finns i hissen och olika tillstånd som dessa kontroller kan vara i.
När du är klar med att utforma klasser och deras relationer kan du prata om att konfigurera DB-scheman.
En annan viktig komponent i hisssystemet är Eventing System. Du kan prata om att implementera köer eller i en mer komplex installation skapa händelseströmmar med hjälp av Apache Kafka där händelserna levereras till respektive system för att hantera.
Eventing System är en viktig aspekt eftersom det finns flera användare (på olika våningar) som använder hissen samtidigt. Därför bör användarens förfrågningar stå i kö och serveras enligt den konfigurerade logiken i hissstyrenheterna.
F # 15) Design Instagram / Twitter / Facebook.
Svar: Alla dessa plattformar är på ett sätt relaterade eftersom de låter användare anslutas på något eller annat sätt och dela saker via olika mediatyper - som meddelanden / videor och chattar också.
Så, för dessa typer av sociala medieapplikationer / plattformar, bör du inkludera nedanstående punkter när du diskuterar utformningen av sådana system (utöver vad vi har diskuterat för att utforma URL-förkortningssystem):
- Uppskattning av kapacitet: De flesta av dessa system skulle vara lästunga, därför krävs kapacitetsuppskattning och gör det möjligt för oss att säkerställa att lämplig server- och databaskonfiguration säkerställs för att tjäna den erforderliga belastningen.
- DB-schema: De viktigaste viktiga DB-scheman som bör diskuteras är - Användardetaljer, Användarförhållanden, Meddelandesscheman, Innehållsscheman.
- Video- och bildservrar: De flesta av dessa applikationer har videor och bilder som delas mellan användare. Därför ska video- och bildhosterservrarna konfigureras enligt behov.
- Säkerhet: Alla dessa appar bör säkerställa en hög säkerhetsnivå på grund av användarinformation / personligt identifierbar information om de användare de lagrar. Alla hackningsförsök, SQL Injection borde inte lyckas på dessa plattformar eftersom det kan kosta att förlora data från miljontals kunder.
Scenariobaserade problem
Scenariobaserade problem är i allmänhet för personer på äldre nivå, där olika realtidsscenarier ges och kandidaten frågas om sina tankar om hur de ska hantera en sådan situation.
F # 16) Med tanke på att en kritisk snabbkorrigering måste släppas så snart som möjligt - Vilken typ av teststrategi skulle du ha?
Svar: Nu, här vill intervjuaren egentligen förstå
- Hur och vilken typ av teststrategier kan du tänka dig?
- Vilken täckning skulle du göra för en snabbkorrigering?
- Hur skulle du validera snabbkorrigeringen efter distributionen? etc.
För att svara på sådana frågor, du kan använda verkliga situationer om du kan relatera till problemet. Du bör också nämna att utan lämplig testning skulle du inte vara villig att släppa någon kod för produktion.
För de kritiska korrigeringarna bör du alltid arbeta tillsammans med utvecklaren och försöka förstå vilka områden det kan påverka och förbereda en icke-produktionsmiljö för att replikera scenariot och testa fixen.
Det är också viktigt här att nämna att du fortsätter att övervaka fixen (med hjälp av övervakningsverktyg, instrumentpaneler, loggar, etc.) efter distribution för att se eventuella onormala beteenden i produktionsmiljön och se till att det inte finns någon negativ inverkan av fixen som är Gjort.
Det kan också finnas andra frågor som främst är för att förstå kandidatens perspektiv på automatiseringstestning, leveranstidslinjer etc (och dessa frågor kan variera företag till företag såväl som rollen i rollen. I allmänhet ställs dessa frågor för senior- / ledningsnivå roller)
F # 17) Skulle du offra fullständig testning för att snabbt släppa en produkt?
Svar: Dessa frågor involverar vanligtvis intervjuaren att förstå dina tankar ur ett ledarskapsperspektiv och vad är de saker som du skulle kompromissa med, och skulle du vara villig att släppa en buggy-produkt istället för kortare tid.
Svaren på dessa frågor bör underbyggas mot kandidatens faktiska erfarenheter.
Till exempel, Du kan nämna att du tidigare var tvungen att ringa för att släppa en snabbkorrigering men det kunde inte testas på grund av att integrationsmiljön inte var tillgänglig. Så du släppte det på ett kontrollerat sätt - genom att rulla ut till en mindre procentsats och sedan övervakade loggar / händelser och sedan initierade full utbyggnad, etc.
F # 18) Hur skulle du skapa automatiseringsstrategi för en produkt som inte har några automatiseringstester alls?
Svar: Dessa typer av frågor är öppna och är i allmänhet ett bra ställe att ta diskussionen på det sätt du vill. Du kan också visa upp dina färdigheter, kunskaper och teknikområden som är din styrka.
Till exempel, för att svara på dessa typer av frågor kan du nämna exempel på automatiseringsstrategi som du antog när du byggde en produkt i din tidigare roll.
Du kan till exempel nämna punkter som,
- Eftersom produkten krävde automatisering från grunden, fick du tillräckligt med tid att tänka och designa för en lämplig automatiseringsram som valde ett språk / teknik som de flesta hade kunskapen för att undvika att införa ett nytt verktyg och utnyttja befintlig kunskap.
- Du började med att automatisera de mest grundläggande funktionella scenarierna som ansågs vara P1 (utan vilka ingen release kunde gå igenom).
- Du tänkte också på att testa systemets prestanda och skalbarhet genom automatiserade testverktyg som JMETER, LoadRunner, etc.
- Du tänkte på att automatisera säkerhetsaspekterna av applikationen enligt listan i OWASP Säkerhetsstandarder.
- Du integrerade de automatiserade testerna i byggpipelinen för tidig feedback etc.
Team Fit & Culture Fit
Denna runda beror vanligtvis på företag till företag. Men behovet / nödvändigheten av den här omgången är att förstå kandidaten ur perspektivet för team- och organisationskulturperspektiv. Syftet med dessa frågor är också att förstå kandidatens personlighet och deras inställning till arbete / människor etc.
Generellt är HR- och anställningschefer de som genomför denna runda.
Frågor som vanligtvis dyker upp under den här omgången är som:
F # 19) Hur löser du konflikter inom din nuvarande roll?
Svar: Ytterligare förklaring här är: antar att du har en konflikt med din chef eller dina omedelbara teammedlemmar, vilka åtgärder tar du för att lösa dessa konflikter?
För denna typ av frågor underbyggs så mycket du kan med verkliga exempel som kan ha hänt inom din karriär hos nuvarande eller tidigare organisationer.
Du kan nämna saker som:
- Du gillar att reda ut eventuella konflikter så snart som möjligt som uppstår på grund av yrkesmässiga skäl (och vill inte påverka dina personliga relationer på grund av dessa).
- Du kan nämna att du i allmänhet försöker kommunicera effektivt och prata / diskutera med personen individuellt för att lösa eventuella skillnader / problem.
- Du kan nämna att om saker börjar bli värre, skulle du ta hjälp av en äldre person / din chef och få hans / hennes insatser.
Andra exempel på team fit / culture fit-frågor finns nedan (de flesta av dem bör besvaras på ett liknande sätt som vi diskuterade för frågan ovan. Att prata om verkliga scenarier är en nyckel här eftersom intervjuaren kan berätta det på ett bättre sätt som väl.
F # 20) Vilken typ av balans mellan arbete och privatliv förväntar du dig av den nya roll som du anses vara anställd för?
Svar: Eftersom Hiring Manager är någon som vet vad rollen kräver, hur mycket extra ansträngning kan krävas ibland, så i allmänhet försöker intervjuaren att mäta om dina förväntningar är radikalt annorlunda än vad rollen förväntar sig.
Antag att du säger att du inte föredrar att delta i nattmöten och rollen förväntar dig att du har ett stort samarbete mellan ett team som sitter i en annan tidszon, då kan intervjuaren inleda en diskussion om att det här är förväntningarna från rollen - Kommer du att kunna anpassa? etc.
Så igen, detta är mer av en avslappnad konversation men ur intervjuarens perspektiv vill de förstå dina förväntningar för att utvärdera din kandidatur för den position som intervjuas för.
F # 21) Vilka är dina fritidsintressen förutom arbete?
Svar: Dessa frågor är rent subjektiva och individspecifika, och dessa frågor är i allmänhet användbara för att få kandidaten att känna sig avslappnad och lätt och inleda avslappnade diskussioner.
I allmänhet kan svaren på dessa frågor vara som - du gillar att läsa en viss genre, du gillar musik, du fick lite pris för någon frivillig / filantropisk aktivitet osv. Dessa frågor ställs vanligtvis i HR-omgången (och mindre benägna att bli ombedd av en teknisk person).
F # 22) Hur mycket tid är du villig att ägna dig åt att lära dig nya verktyg och tekniker proaktivt?
Svar: Här mäter intervjuaren din vilja att lära dig nya saker om något ovanligt eller nytt kastas mot dig. Det låter också intervjuaren veta att du är proaktiv? Är du villig att investera i dig själv och din karriär? etc.
Så när du svarar på sådana frågor - var ärlig och underbygg dina svar med exempel - Till exempel, Du kan nämna att du dök upp för en Java-certifiering förra året och förberedde dig utanför arbetet genom att ta några timmar varje vecka.
Slutsats
I den här artikeln diskuterade vi Software Development Engineer i testintervjuprocessen och exempelfrågor som vanligtvis ställs från kandidaterna i olika organisationer och profiler. Generellt sett är SDET-intervjuer mycket breda och mycket beroende av företag till företag.
Men intervjuprocesserna liknar vad som finns för en utvecklarprofil med större tonvikt på kvalitets- och automatiseringsramar.
Det är viktigt att förstå att företag idag är mindre fokuserade på något specifikt språk eller teknik, men mer om en bred förståelse av begrepp och förmågan att anpassa sig till de verktyg / tekniker som krävs av företaget.
Bästa hälsningar för din SDET-intervju!
Rekommenderad läsning
- Vad är SDET: Vet skillnaden mellan testare och SDET
- Intervjufrågor och svar
- ETL Testing Intervju Frågor och svar
- Några knepiga manuella testfrågor och svar
- Spock intervjufrågor med svar (mest populära)
- 25 bästa intervjuer och svar på Agile Testing
- Topp 32 bästa datastationsintervjuer och frågor
- Topp 20+ .NET-intervjufrågor och svar