SDET-intervjufrågor och svar (komplett guide)

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

1. Grunderna för operativsystem: Personsökning, filsystem, virtuellt minne och fysiskt minne etc.
2. Nätverkskoncept: HTTP-kommunikation, TCP / IP-stack, nätverkstopologier.
3. Skalbarhetskoncept: Horisontell och vertikal skalning.
4. Samtidighet / gängningskoncept
5. Databastyper: SQL / Inga SQL-databaser, när ska man använda vilken typ av databas, fördelar och nackdelar med olika typer av databaser.
6. Hashing tekniker
7. 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,

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:

• 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

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:

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