sdet interview questions
Leggi questa guida completa al Software Development Engineer in Test Interviews per conoscere il formato e come rispondere alle domande dell'intervista SDET poste nei vari round:
In questo tutorial, apprenderemo alcune domande frequenti per i colloqui per i ruoli SDET. Vedremo anche, in generale, lo schema comune delle interviste e condivideremo alcuni suggerimenti per eccellere nelle interviste.
Useremo il linguaggio Java per i problemi di codifica per questo tutorial, tuttavia, la maggior parte dei tutorial SDET sono indipendenti dalla lingua e gli intervistatori sono generalmente flessibili riguardo alla lingua che il candidato sceglie di utilizzare.
Cosa imparerai:
Guida alla preparazione dell'intervista SDET
Le interviste SDET, nella maggior parte delle principali società di prodotti, sono abbastanza simili al modo in cui vengono condotte le interviste per i ruoli di sviluppo. Questo perché ci si aspetta che anche gli SDET conoscano e comprendano ampiamente quasi tutto ciò che lo sviluppatore sa.
Ciò che differisce sono i criteri in base ai quali viene giudicato l'intervistato SDET. Gli intervistatori per questo ruolo cercano capacità di pensiero critico, nonché se la persona intervistata ha esperienza pratica nella programmazione e ha un occhio per la qualità e il dettaglio.
Ecco alcuni punti su cui chi si prepara per un'intervista SDET dovrebbe concentrarsi principalmente:
come usare thread.sleep in java
- Poiché, la maggior parte delle volte, queste interviste sono indipendenti dalla tecnologia / dalla lingua, i candidati devono essere disposti ad apprendere nuove tecnologie (e sfruttare le competenze esistenti) come e quando richiesto.
- Dovrebbe avere una buona comunicazione e capacità di squadra poiché i ruoli SDET oggigiorno richiedono comunicazione e collaborazione a vari livelli con più parti interessate.
- Dovrebbe avere una conoscenza di base dei diversi concetti di progettazione del sistema, scalabilità, concorrenza, requisiti non funzionali, ecc.
Nelle sezioni seguenti, proveremo a comprendere il formato generale dell'intervista insieme ad alcune domande di esempio.
Format Of Software Development Engineer in Test Interview
La maggior parte delle aziende ha il proprio formato preferito per intervistare i candidati per un ruolo SDET poiché a volte il ruolo è super specifico per un team e ci si aspetta che la persona sia valutata come una misura perfetta per il team per cui viene assunta.
Ma il tema delle interviste si basa generalmente sui seguenti punti:
- Discussione telefonica: Conversazione con il manager e / oi membri del team che di solito è un round di screening.
- Turno scritto: Con domande specifiche di test / test case.
- Competenza di codifica round: Semplici domande di codifica (indipendenti dalla lingua) e al candidato viene chiesto di scrivere codice a livello di produzione.
- Comprensione dei concetti di sviluppo di base: Come i concetti OOPS, i principi SOLID, ecc.
- Progettazione e sviluppo di Test Automation Framework
- Linguaggi di scripting: Selenio, Python, Javascript, ecc
- Cultura Fit / Discussione e negoziazioni sulle risorse umane
Domande e risposte dell'intervista SDET
In questa sezione, discuteremo alcune domande di esempio insieme a risposte dettagliate, per diverse categorie che vengono poste dalla maggior parte delle società di prodotto che assumono per ruoli SDET.
Competenza nella codifica
In questo round, vengono forniti semplici problemi di codifica da scrivere nella lingua prescelta. Qui, l'intervistatore vuole valutare la competenza con i costrutti di codifica e gestire cose come scenari limite e controlli nulli, ecc.
Occasionalmente, gli intervistatori potrebbero anche chiedere di scrivere dei test unitari per il programma scritto.
Vediamo alcuni problemi di esempio.
D # 1) Scrivi un programma per scambiare 2 numeri senza usare la terza variabile (temporanea)?
Risposta :
Programma per scambiare due numeri:
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); } }
Ecco l'output dello snippet di codice sopra:
Nello snippet di codice sopra, è importante notare che l'intervistatore ha specificamente chiesto di scambiare 2 no senza utilizzare una terza variabile temporanea. Inoltre, è importante che prima di inviare la soluzione, si consiglia sempre di esaminare (o eseguire il dry run) il codice per almeno 2-3 input. Proviamo con valori positivi e negativi.
Valori positivi: 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)
Valori negativi: 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) Scrivi un programma per invertire un numero?
Risposta: L'affermazione del problema potrebbe inizialmente sembrare intimidatoria, ma è sempre saggio chiedere chiarimenti all'intervistatore (ma non molti dettagli). Gli intervistatori possono scegliere di fornire suggerimenti sul problema, ma se il candidato fa molte domande, allora indica anche al candidato che non ha dato abbastanza tempo per capire bene il problema.
Qui, il problema si aspetta che anche un candidato faccia alcune supposizioni: per esempio, il numero potrebbe essere un numero intero. Se l'input è 345, l'output dovrebbe essere 543 (che è il contrario di 345)
Vediamo lo snippet di codice per questa soluzione:
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 per questo programma contro input : 10025 - Previsto sarebbe : 52001
D # 3) Scrivi un programma per calcolare il fattoriale di un numero?
Risposta: Il fattoriale è una delle domande più frequenti in quasi tutte le interviste (comprese le interviste agli sviluppatori)
Per le interviste agli sviluppatori, l'attenzione si concentra maggiormente sui concetti di programmazione come la programmazione dinamica, la ricorsione, ecc., Mentre dall'Ingegnere di sviluppo software in prospettiva Test, è importante gestire gli scenari limite come valori massimi, valori minimi, valori negativi, ecc. E approccio / efficienza sono importanti ma diventano secondarie.
Vediamo un programma per fattoriale che utilizza la ricorsione e il ciclo for con la gestione di numeri negativi e restituisce un valore fisso di diciamo -9999 per i numeri negativi che dovrebbero essere gestiti nel programma che chiama la funzione fattoriale.
Fare riferimento allo snippet di codice di seguito:
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); } }
Vediamo l'output per - fattoriale usando il ciclo, fattoriale usando la ricorsione e fattoriale di un numero negativo (che restituirebbe un valore predefinito di -9999)
D # 4) Scrivere un programma per verificare se una data stringa ha parentesi bilanciate?
Risposta:
Approccio - Questo è un problema leggermente complesso, in cui l'intervistatore sta guardando leggermente più della semplice conoscenza dei costrutti di codifica. Qui, l'aspettativa è pensare e utilizzare la struttura dati apt per il problema in questione.
Molti di voi potrebbero sentirsi intimiditi da questo tipo di problemi, poiché alcuni di voi potrebbero non averli sentiti e quindi, anche se sono semplici, potrebbero sembrare complessi.
Ma generalmente per tali problemi / domande: ad esempio, nella domanda attuale, se non sai cosa sono le parentesi equilibrate, puoi benissimo chiedere all'intervistatore e poi lavorare per la soluzione invece di trovare un punto cieco.
Vediamo come affrontare una soluzione: Dopo aver compreso cosa sono le parentesi bilanciate, puoi pensare di utilizzare la struttura dati corretta e quindi iniziare a scrivere algoritmi (passaggi) prima di iniziare a codificare la soluzione. Molte volte, gli algoritmi stessi risolvono molti scenari estremi e danno molta chiarezza su come sarà la soluzione.
Diamo un'occhiata alla soluzione:
Le parentesi bilanciate servono a verificare la presenza di una determinata stringa che contiene parentesi (o parentesi), deve avere un conteggio di apertura e chiusura uguale e ben strutturata dal punto di vista della posizione. Per il contesto di questo problema, useremo parentesi bilanciate come - '()', '()', '{}' - cioè la stringa data può avere qualsiasi combinazione di queste parentesi.
Si prega di notare che prima di tentare il problema, è bene chiarire se la stringa conterrà solo i caratteri delle parentesi o qualsiasi numero, ecc. (Poiché ciò potrebbe modificare un po 'la logica)
Esempio: Una data stringa - '{() {} ()} - è una stringa bilanciata in quanto è strutturata e ha uguale numero di parentesi di chiusura e apertura, ma stringa -' {(}) {} () '- questa stringa - anche se ha uguale numero di parentesi di apertura e chiusura questo non è ancora bilanciato perché puoi vedere che senza una chiusura '(' abbiamo chiuso '}' (cioè tutte le parentesi interne dovrebbero essere chiuse prima di chiudere una parentesi esterna)
Useremo una struttura di dati dello stack per risolvere questo problema. Se vuoi saperne di più sulle basi dello stack, fai riferimento Qui
Una pila è un LIFO (tipo di struttura dati Last In First Out), pensala come una pila / pila di piatti a un matrimonio: raccoglierai il piatto più in alto ogni volta che lo usi.
Algoritmo:
# 1) Dichiarare una pila di caratteri (che conterrebbe i caratteri nella stringa e, a seconda di una logica, spingere e far uscire i caratteri).
# 2) Attraversa la stringa di input e ogni volta
- È presente un carattere di parentesi graffa di apertura, ad esempio '(', {'o' ('), sposta il carattere sulla pila.
- C'è un carattere di chiusura - cioè ')', '}', ')' - fai apparire un elemento da Stack e controlla se corrisponde al contrario del carattere di chiusura - cioè se il carattere è '}', allora su Stack pop dovresti aspettarti ' {'
- Se l'elemento scoppiato non corrisponde alle parentesi di chiusura, la stringa non è bilanciata e puoi restituire i risultati.
- Altrimenti continua con l'approccio push e pop dello stack (vai al passaggio 2).
- Se la stringa viene attraversata completamente e anche la dimensione dello Stack è zero, allora possiamo dire / dedurre che la stringa data è una stringa di parentesi bilanciate.
A questo punto, potresti anche voler discutere l'approccio alla soluzione che hai come algoritmo e assicurarti che l'intervistatore sia d'accordo con l'approccio.
Codice:
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 L'output dello snippet di codice sopra:

Come abbiamo fatto per i nostri precedenti problemi di codifica, è sempre bene eseguire il codice con almeno 1-2 input validi e 1-2 input non validi e assicurarsi che tutti i casi siano gestiti in modo appropriato.
NOTA: È sempre bene pensare ad alta voce la soluzione (e non solo nella mente) - e sorprendentemente questo è un tratto importante che gli intervistatori stanno cercando. Molti intervistatori potrebbero semplicemente eliminare l'algoritmo e passare alla successiva dichiarazione del problema.
Nella soluzione di codifica sopra, per l'intervista allo sviluppatore, l'intervistatore potrebbe chiedere di risolverlo utilizzando array invece di stack direttamente (ovvero utilizzando array come stack), ma in generale, si tratta più di essere concettualmente chiari e in grado di gestire tutti input non validi.
Relativo al framework di automazione del test
Questa sezione dell'intervista è più specifica sui test e sulle responsabilità SDET. Aspettatevi la progettazione del framework di automazione e le domande relative allo sviluppo, pro e contro dell'utilizzo di approcci diversi, ecc.
Vediamo alcune domande e soluzioni di esempio per lo stesso.
D # 5) Spiegare e progettare i componenti del framework di automazione per un'applicazione web?
Risposta: Questa domanda è un po 'soggettiva e l'intervistatore intende valutare quanto il candidato sa della progettazione e dello sviluppo del framework. La risposta a questa domanda aiuta l'intervistatore a capire se il candidato può costruire o creare quadri personalizzati da zero.
Vediamo un paio di punti che potrebbero aiutarti a strutturare la soluzione per questa domanda:
- Puoi parlare di diversi tipi di framework come: Data-driven, Keyword-driven, Hybrid Framework.
- Page Object Model per memorizzare i dettagli di vari elementi su diverse pagine / moduli dell'applicazione web.
- Moduli comuni come funzioni di supporto, utilità, logger, ecc.
- Moduli di reportistica come la generazione di report di esecuzione di test, l'integrazione di report con e-mail e la pianificazione dell'esecuzione di test, ecc.
Lettura consigliata => I framework di automazione dei test più popolari
D # 6) Spiegare le strategie di test per un'applicazione mobile?
Risposta: Queste domande vengono generalmente poste a seconda del ruolo. Se il ruolo è principalmente quello di lavorare su app mobili, la domanda ha più rilevanza. Puoi parlare della tua esperienza se hai pianificato test mobili come parte dei tuoi ruoli attuali o precedenti.
Alcuni suggerimenti per strutturare la risposta a questa domanda potrebbero essere,
- Test su dispositivi vs emulatori.
- Identificazione e memorizzazione di oggetti / elementi su schermi diversi - Esempio: Modello a oggetti della pagina.
- Prova di carico di un'applicazione mobile.
- Puoi parlare di diversi tipi di applicazioni mobili come: app native, app ibride e discutere strategie / approcci che useresti per testarle.
Lettura consigliata => Tutorial per test di app per dispositivi mobili
D # 7) Progettare un framework di automazione per testare le API REST?
Risposta: Anche questa è una domanda soggettiva e puoi porre domande di chiarimento se l'intervistatore desidera che tu sviluppi un framework per testare il comportamento funzionale dell'API o requisiti non funzionali come il test di carico / prestazioni.
Puoi iniziare la tua risposta coprendo i seguenti punti:
- Componenti del framework di automazione API come configurazione locale, configurazione fittizia dell'API o test API ospitato.
- Strumenti utilizzati per l'automazione delle API. Sono disponibili diversi strumenti pronti all'uso per convalidare gli aspetti funzionali di un'API basata su REST. Alcuni di questi strumenti sono Postman, Rest Assured, ecc. Per dettagli approfonditi sui diversi strumenti, puoi fare riferimento al nostro articolo Qui .
- Automazione non funzionale delle API.
- Esecuzione programmata di test di automazione.
- Integrazione dei test di automazione per le API.
Q # 8) Domande specifiche del framework.
Risposta: A volte, a seconda del profilo che viene intervistato, potrebbe esserci un requisito per un candidato di essere competente con un determinato quadro - es. Selenio, JMeter, ecc.
Lettura consigliata => Postino , Mockito , Specflow , Selenio , JMeter
Test correlati
Sebbene raramente, ma a seconda del profilo, potrebbero sorgere domande sulle pratiche generali di test, termini e tecnologie - come gravità dei bug, priorità, pianificazione dei test, test case, ecc. Ci si aspetta che uno SDET conosca tutti i concetti di test manuali e dovrebbe essere familiare con le terminologie importanti.
In questa sezione, puoi aspettarti domande come queste:
D # 9) Quali sono i diversi componenti di un piano di test?
Risposta: A questi viene generalmente chiesto di convalidare i concetti e la mentalità di base dei test. Questi termini e documenti sono qualcosa che ogni QA manuale e SDET di automazione dovrebbero conoscere.
Puoi discutere i vari componenti del piano di test qui come,
- Criteri di ingresso e di uscita
- Scopo: Discuti le funzionalità di test che rientrano nell'ambito e ciò che sarebbe automatizzato: saranno solo caratteristiche funzionali o requisiti non funzionali come scalabilità, prestazioni, ecc.
- Linea del tempo
- Strumenti da utilizzare
- Allocazione delle risorse, ecc
Lettura consigliata => Come scrivere un buon piano di test
Q # 10) Cosa definisce e decide la priorità e la gravità di un bug?
Risposta: Priorità e gravità dei difetti possono essere facilmente spiegate con l'aiuto di esempi. Supponiamo che una funzione come la registrazione non funzioni e impedisca agli utenti di accedere all'applicazione: si tratta di un problema di alta priorità e gravità elevata. Allo stesso modo, possono esserci esempi di difetti di bassa gravità / alta priorità e varie altre combinazioni.
In generale,
- Priorità indica l'importanza del problema.
- Gravità indica l'impatto che il problema sta avendo per il cliente o l'utente dell'applicazione.
Lettura consigliata => Priorità e gravità dei difetti
D # 11) Che cos'è il partizionamento di equivalenza? Illustra con un esempio.
Risposta: Il partizionamento di equivalenza è una tecnica utilizzata principalmente per il test della scatola nera, per testare varie combinazioni di input su un determinato campo.
Per esempio, se stai testando un'applicazione di trading e desideri scrivere tutti gli scenari di test per il campo 'Quantità', quali sarebbero i diversi input che testeresti per questo campo?
Dato il requisito funzionale, la quantità deve essere un valore intero positivo compreso tra 1 e 100000. Quindi, per testare vari input (sia validi che non validi), è possibile eseguire test per 1 input da ciascuna di tali categorie.
- Valori validi: Tra 1 e 100000 -> verifica qualsiasi valore x valido tale che x> 1 e x<100000.
- Valori limite: Verifica i valori limite consentiti, ad esempio 1 e 100000.
- Valori non validi: Valori che si trovano al di fuori dell'intervallo consentito, ovvero verifica uno di questi valori per x, tale che x 100000.
Lettura consigliata => Strategia di partizionamento di equivalenza
Relativo alla progettazione del sistema
Le domande sulla progettazione del sistema sono in genere più adatte per le interviste agli sviluppatori in cui uno sviluppatore viene giudicato in base a un'ampia comprensione di diversi concetti generali, come scalabilità, disponibilità, tolleranza ai guasti, selezione del database, threading, ecc. In poche parole, dovrai utilizzare tutto il tuo esperienza e conoscenza dei sistemi per rispondere a tali domande.
Ma potresti sentire che un sistema che richiede anni di esperienza e centinaia di sviluppatori per codificare, come potrebbe una persona rispondere alla domanda in circa 45 minuti?
La risposta è: Qui l'aspettativa è di giudicare la comprensione del candidato e l'ampio spettro di conoscenze che lui o lei può applicare mentre risolve problemi complessi.
Oggigiorno, queste domande iniziano a essere poste anche nelle interviste SDET. Qui l'aspettativa rimane la stessa dell'intervista allo sviluppatore, ma con criteri di giudizio rilassati e si tratta principalmente di un giro di bar in cui, a seconda della risposta del candidato, un candidato può essere considerato per il livello successivo o spostato a un livello inferiore.
In generale, per le domande del colloquio sulla progettazione del sistema, il candidato deve avere familiarità con i concetti seguenti
- Nozioni di base sui sistemi operativi: Paging, file system, memoria virtuale e memoria fisica, ecc.
- Concetti di rete: Comunicazione HTTP, stack TCP / IP, topologie di rete.
- Concetti di scalabilità: Ridimensionamento orizzontale e verticale.
- Concetti di concorrenza / threading
- Tipi di database: Database SQL / No SQL, quando utilizzare quale tipo di database, vantaggi e svantaggi dei diversi tipi di database.
- Tecniche di hashing
- Comprensione di base di CAP teorema, partizionamento, partizionamento, ecc.
Vediamo alcune domande di esempio
D # 12) Progetta un sistema di accorciamento degli URL come un file URL minuscolo ?
Risposta: Molti candidati potrebbero anche non conoscere i sistemi di abbreviazione degli URL in generale. In tal caso, va bene chiedere all'intervistatore la dichiarazione del problema invece di immergersi senza capire.
Prima ancora di rispondere a tali domande, i candidati dovrebbero strutturare la soluzione e scrivere elenchi puntati e quindi iniziare a discutere la soluzione con l'intervistatore.
Discutiamo brevemente la soluzione
a) Chiarire i requisiti funzionali e non funzionali
Richieste funzionali: Il requisito funzionale è semplicemente dal punto di vista di un cliente, è un sistema che riceve un URL grande (di lunga lunghezza) e l'output dovrebbe essere un URL abbreviato.
Quando si accede all'URL abbreviato, dovrebbe reindirizzare l'utente all'URL originale. Per esempio - prova ad accorciare un URL effettivo nella pagina web https://tinyurl.com/, inserisci un URL di input come www.softwaretestinghelp.com e dovresti ottenere un URL minuscolo come https://tinyurl.com/shclcqa
Requisiti non funzionali: Il sistema dovrebbe essere performante in termini di reindirizzamento con una latenza di millisecondi (poiché è un salto aggiuntivo per un utente che accede all'URL originale).
- Gli URL abbreviati dovrebbero avere una scadenza configurabile.
- Gli URL abbreviati non dovrebbero essere prevedibili.
b) Capacità / Stima del traffico
Questo è molto importante dal punto di vista di tutte le domande sulla progettazione del sistema. La stima della capacità determina essenzialmente il carico previsto che il sistema riceverà. È sempre bene iniziare con un presupposto e discutere con l'intervistatore. Questo è importante anche dal punto di vista della pianificazione del dimensionamento del database, se il sistema è pesante in lettura o in scrittura, ecc.
Facciamo alcuni numeri di capacità per l'esempio di accorciatore di URL.
Supponiamo che ci saranno 100.000 nuove richieste di accorciamento URL al giorno (con un rapporto di lettura / scrittura di 100: 1, ovvero per ogni URL abbreviato 1, avremo 100 richieste di lettura contro l'URL abbreviato)
Quindi avremo,
100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second
c) Considerazioni su archiviazione e memoria
Dopo i numeri di capacità, possiamo estrapolare questi numeri per ottenere,
- La capacità di stoccaggio necessaria per accogliere il carico previsto, Per esempio, possiamo pianificare di progettare una soluzione di archiviazione per supportare le richieste fino a 1 anno.
Esempio: Se ogni URL abbreviato consuma 50 byte, il totale dei dati / spazio di archiviazione che avremmo richiesto in un anno sarebbe:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
- Le considerazioni sulla memoria sono importanti per pianificare il sistema dal punto di vista del lettore. cioè per i sistemi che sono pesanti in lettura, come quello che stiamo cercando di creare (perché l'URL verrebbe creato una volta ma vi si accede più volte).
I sistemi pesanti di lettura generalmente utilizzano la memorizzazione nella cache per diventare più performanti ed evitare di leggere dalla memoria permanente per salvare sull'I / O di lettura.
Supponiamo di voler memorizzare il 60% delle nostre richieste di lettura nella cache, quindi nel corso dell'anno avremmo richiesto il 60% delle letture totali nell'anno x byte richiesti da ciascuna voce
=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GB
Quindi, secondo i nostri numeri di capacità, questo sistema richiederebbe circa 1 GB di memoria fisica
d) Stime della larghezza di banda
Le stime della larghezza di banda sono necessarie per analizzare la velocità di lettura e scrittura in byte che sarebbe necessaria per l'esecuzione di un sistema. Facciamo delle stime rispetto ai numeri di capacità che abbiamo preso.
Esempio: Se ogni URL abbreviato consuma 50 byte, le velocità totali di lettura e scrittura di cui avremmo bisogno sarebbero le seguenti:
WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s
e) Progettazione del sistema e algoritmo
Questa è essenzialmente la logica o l'algoritmo di business principale che verrebbe utilizzato per soddisfare i requisiti funzionali. In questo caso, vogliamo generare URL accorciati univoci per un determinato URL.
I diversi approcci che potrebbero essere utilizzati per generare URL abbreviati sono:
Hashing: Possiamo pensare di generare URL abbreviati creando un hash dell'URL di input e assegnando la chiave hash come URL abbreviato.

Questo approccio potrebbe avere alcuni problemi quando ci sono diversi utenti del servizio e se inseriscono lo stesso URL, si otterrebbe lo stesso URL abbreviato.
Stringhe accorciate pre-createe assegnato agli URL quando viene chiamato il servizio: Un altro approccio può essere quello di restituire una stringa abbreviata predefinita dal pool di stringhe già generate.

API di servizio: Possiamo pensare al sistema di abbreviazione di URL come a un insieme di API basate su REST che hanno i seguenti endpoint:
- createUrl (String Url, DateTime expiryTime): Questo endpoint crea e restituisce un URL abbreviato con durata di scadenza impostata come specificato nell'input.
- retrieveUrl (String shortenedUrl): Questo endpoint recupera l'URL da reindirizzare verso l'URL abbreviato specificato.
f) Scalabilità e concorrenza
Il ridimensionamento è una considerazione importante dal punto di vista dei requisiti non funzionali.
Si occupa di, come può sistema
- Bilancia sotto carico: Il sistema dovrebbe essere in grado di scalare con garbo sotto carico e non solo smettere di funzionare dopo un picco imprevisto nel carico.
Lettura consigliata => Tecniche di ridimensionamento
- Quanto può essere performante il sistema, per esempio: se il sistema viene utilizzato con capacità sostenuta per un lungo periodo, le prestazioni del sistema peggiorano o rimangono stabili?
Ci possono essere molte diverse domande sulla progettazione del sistema come di seguito, ma in generale, tutte queste metterebbero alla prova la comprensione più ampia del candidato dei diversi concetti che abbiamo discusso nella soluzione del sistema di accorciamento degli URL.
D # 13) Progetta una piattaforma video come Youtube.
Risposta: Questa domanda può anche essere affrontata, in un modo simile a come abbiamo discusso la domanda di TinyUrl sopra (e questo vale per quasi tutte le domande dell'intervista sulla progettazione del sistema). L'unico fattore di differenziazione sarebbe guardare / dettagliare il sistema che si desidera progettare.
Quindi per Youtube, sappiamo tutti che è un'applicazione di streaming video e ha molte funzionalità come consentire a un utente di caricare nuovi video, trasmettere in streaming webcast dal vivo, ecc. Quindi, durante la progettazione del sistema, è necessario applicare i componenti di progettazione del sistema richiesti. In questo caso, potrebbe essere necessario aggiungere componenti relativi alle funzionalità di streaming video.
Puoi discutere punti come,
- Conservazione: Che tipo di database sceglieresti per archiviare contenuti video, profili utente, playlist, ecc.?
- Sicurezza e autenticazione / autorizzazione
- Memorizzazione nella cache: Poiché una piattaforma di streaming come YouTube dovrebbe essere performante, la memorizzazione nella cache è un fattore importante per la progettazione di qualsiasi sistema di questo tipo.
- Concorrenza: Quanti utenti possono riprodurre video in streaming in parallelo?
- Altre funzionalità della piattaforma come il servizio di consigli video che consiglia / suggerisce agli utenti i prossimi video che possono guardare ecc.
D # 14) Progettare un sistema efficiente per il funzionamento di 6 ascensori e assicurarsi che una persona debba attendere un tempo minimo in attesa dell'arrivo dell'ascensore ?
Risposta: Questi tipi di domande sulla progettazione del sistema sono di livello più basso e si aspetterebbe che il candidato pensi prima al sistema dell'ascensore ed elenchi tutte le possibili funzioni che devono essere supportate e progetta / crea classi e relazioni / schemi DB come soluzione.
Dal punto di vista di SDET, l'intervistatore si aspetterebbe solo le classi principali che secondo te la tua applicazione o sistema avrebbe e le funzionalità di base sarebbero gestite con la soluzione suggerita.
Vediamo le varie funzionalità del sistema di ascensori che ci si aspetterebbe
Puoi fare domande chiarenti come
- Quanti piani ci sono?
- Quanti ascensori ci sono?
- Tutti gli ascensori sono di servizio / ascensori passeggeri?
- Tutti gli ascensori sono configurati per essere fermati su ogni piano?
Ecco i diversi casi d'uso applicabili per un semplice sistema di ascensore:

In termini di classi / oggetti principali di questo sistema, puoi considerare di avere:
- Utente: Si occupa di tutte le proprietà di un utente e delle azioni che può intraprendere su Elevator Object.
- Ascensore: Elevatore Proprietà specifiche come altezza, larghezza, lift_serial_number.
- Porta dell'ascensore: Tutte le cose relative alla porta come nessuna porta, tipo di porta, automatica o manuale, ecc.
- Elevator_Button_Control: Diversi pulsanti / controlli disponibili nell'ascensore e diversi stati in cui possono trovarsi tali controlli.
Una volta che hai finito, progettando le classi e le loro relazioni, puoi parlare della configurazione degli schemi DB.
Un altro componente importante del sistema ascensore è Eventing System. Si può parlare di implementazione di code o in una configurazione più complessa creazione di flussi di eventi utilizzando Apache Kafka in cui gli eventi vengono consegnati ai rispettivi sistemi per agire.
Eventing System è un aspetto importante in quanto vi sono più utenti (su piani diversi) che utilizzano l'ascensore contemporaneamente. Quindi le richieste dell'utente dovrebbero essere messe in coda e servite secondo la logica configurata nei controller Elevator.
D # 15) Progetta Instagram / Twitter / Facebook.
Risposta: Tutte queste piattaforme sono in un certo senso correlate poiché consentono agli utenti di essere collegati in un modo o nell'altro e di condividere cose tramite diversi tipi di media, come messaggi / video e anche chat.
Quindi, per questi tipi di applicazioni / piattaforme di social media, dovresti includere i seguenti punti mentre parli della progettazione di tali sistemi (oltre a ciò che abbiamo discusso per la progettazione del sistema di abbreviazione degli URL):
- Stima della capacità: La maggior parte di questi sistemi sarebbe pesante in lettura, quindi è necessaria una stima della capacità e ci consentirebbe di garantire che la configurazione appropriata del server e del database sia assicurata per soddisfare il carico richiesto.
- Schema DB: I principali schemi di database importanti che dovrebbero essere discussi sono: dettagli utente, relazioni utente, schemi di messaggi, schemi di contenuto.
- Server di hosting di video e immagini: La maggior parte di queste applicazioni ha video e immagini condivise tra gli utenti. Quindi i server di hosting di video e immagini dovrebbero essere configurati secondo le esigenze.
- Sicurezza: Tutte queste app dovrebbero garantire un elevato livello di sicurezza grazie alle informazioni sull'utente / informazioni di identificazione personale degli utenti che memorizzano. Qualsiasi tentativo di hacking, SQL Injection non dovrebbe avere successo su queste piattaforme in quanto potrebbe costare la perdita di dati di milioni di clienti.
Problemi basati sullo scenario
I problemi basati sugli scenari sono generalmente per le persone di livello senior, in cui vengono forniti diversi scenari in tempo reale e al candidato viene chiesto i suoi pensieri su come gestirà una situazione del genere.
D # 16) Dato che un hotfix critico deve essere rilasciato il prima possibile - Che tipo di strategia di test avresti?
Risposta: Ora, qui l'intervistatore vuole essenzialmente capire
- Come e che tipo di strategie di test puoi pensare?
- Che copertura faresti per un hotfix?
- Come convalideresti l'hotfix dopo la distribuzione? eccetera.
Per rispondere a queste domande, potresti usare situazioni di vita reale se potessi metterti in relazione con il problema. Dovresti anche menzionare che senza test appropriati, non saresti disposto a rilasciare alcun codice in produzione.
Per le correzioni critiche, dovresti sempre lavorare in tandem con lo sviluppatore e cercare di capire quali aree potrebbe avere un impatto e preparare un ambiente non di produzione per replicare lo scenario e testare la correzione.
È anche importante qui menzionare che continuerai a monitorare la correzione (utilizzando strumenti di monitoraggio, dashboard, registri, ecc.) Dopo la distribuzione per vedere qualsiasi comportamento anomalo nell'ambiente di produzione e assicurarti che non vi sia alcun impatto negativo della correzione che è fatto.
Potrebbero esserci anche altre domande che servono principalmente a comprendere il punto di vista del candidato sui test di automazione, i tempi di consegna, ecc. (E queste domande possono variare da azienda a azienda così come l'anzianità del ruolo. Generalmente queste domande sono poste a livello senior / lead ruoli)
D # 17) Sacrificheresti i test completi per rilasciare rapidamente un prodotto?
Risposta: Queste domande in genere coinvolgono l'intervistatore per comprendere i tuoi pensieri da una prospettiva di leadership e quali sono le cose su cui vorresti scendere a compromessi, e saresti disposto a rilasciare un prodotto difettoso invece di meno tempo.
Le risposte a queste domande dovrebbero essere comprovate rispetto alle effettive esperienze del candidato.
Per esempio, potresti menzionare che in passato dovevi rispondere a una chiamata per rilasciare alcuni hotfix ma non è stato possibile testarlo a causa della non disponibilità dell'ambiente di integrazione. Quindi l'hai rilasciato in modo controllato, distribuendo una percentuale inferiore e quindi monitorando i registri / eventi e quindi avviato l'implementazione completa, ecc.
D # 18) Come creeresti una strategia di automazione per un prodotto che non ha affatto test di automazione?
Risposta: Questi tipi di domande sono a risposta aperta e generalmente sono un buon posto per portare la discussione nel modo desiderato. Puoi anche mostrare le tue abilità, conoscenze e aree tecnologiche che sono i tuoi punti di forza.
Per esempio, per rispondere a questi tipi di domande, puoi citare esempi di strategia di automazione che hai adottato durante la creazione di un prodotto nel tuo ruolo passato.
Ad esempio, potresti menzionare punti come,
- Poiché il prodotto richiedeva l'avvio dell'automazione da zero, si disponeva di tempo sufficiente per pensare e progettare un framework di automazione appropriato scegliendo un linguaggio / tecnologia che la maggior parte delle persone aveva la conoscenza per evitare di introdurre un nuovo strumento e sfruttare le conoscenze esistenti.
- Hai iniziato con l'automazione degli scenari funzionali più basilari che erano considerati P1 (senza i quali nessuna versione poteva essere eseguita).
- Hai anche pensato di testare le prestazioni e la scalabilità del sistema attraverso strumenti di test automatizzati come JMETER, LoadRunner, ecc.
- Hai pensato di automatizzare gli aspetti di sicurezza dell'applicazione come elencato nel OWASP Standard di sicurezza.
- Hai integrato i test automatizzati nella pipeline di build per un feedback iniziale, ecc.
In forma di squadra e cultura
Questo round dipende generalmente da società a società. Ma la necessità / necessità per questo round è comprendere il candidato dal punto di vista della cultura del team e dell'organizzazione. Lo scopo di queste domande è anche quello di comprendere la personalità del candidato e il suo approccio al lavoro / alle persone, ecc.
In generale, i responsabili delle risorse umane e delle assunzioni sono quelli che conducono questo round.
Le domande che di solito sorgono durante questo round sono come:
D # 19) Come risolvete i conflitti all'interno del vostro ruolo attuale?
Risposta: Un'ulteriore spiegazione qui è: supponiamo che tu abbia un conflitto con il tuo capo o con i membri immediati del team, quali sono i passaggi che intraprendi per risolvere tali conflitti?
Per questo tipo di domande, motivare il più possibile con esempi reali che potrebbero essersi verificati nella tua carriera presso organizzazioni attuali o precedenti.
Puoi menzionare cose come:
- Ti piace risolvere al più presto eventuali conflitti che sorgono a causa di motivi professionali (e non vorresti influenzare i tuoi rapporti personali a causa di questi).
- Puoi dire che generalmente cerchi di comunicare in modo efficace e di parlare / discutere con la persona individualmente per risolvere eventuali differenze / problemi.
- Puoi dire che se le cose iniziano a peggiorare, prenderesti l'aiuto di una persona anziana / il tuo manager e riceverai i suoi input.
Di seguito sono riportati altri esempi di domande di adattamento al team / adattamento alla cultura (la maggior parte di esse dovrebbe ricevere una risposta con un approccio simile che abbiamo discusso per la domanda sopra. Parlare di scenari di vita reale è una chiave qui poiché l'intervistatore può relazionarlo in un modo migliore in quanto bene.
D # 20) Che tipo di equilibrio tra lavoro e vita privata ti aspetti dal nuovo ruolo per il quale sei considerato assunto?
Risposta: Poiché il responsabile delle assunzioni è qualcuno che sa cosa richiede il ruolo, quanto sforzo extra potrebbe essere richiesto a volte, quindi in generale l'intervistatore cerca di valutare se le tue aspettative sono radicalmente diverse da ciò che il ruolo si aspetta.
Supponi di dire che non preferisci partecipare alle riunioni notturne e il ruolo si aspetta che tu abbia una collaborazione importante tra un team che si trova in un fuso orario diverso, quindi l'intervistatore potrebbe avviare una discussione che queste sono le aspettative dal ruolo - Sarai in grado di adattare? eccetera.
Quindi, ancora una volta, questa è più una conversazione casuale ma dal punto di vista dell'intervistatore, vuole capire le tue aspettative per valutare la tua candidatura per la posizione per la quale viene intervistato.
D # 21) A parte il lavoro, quali sono i tuoi hobby?
Risposta: Queste domande sono puramente soggettive e specifiche per individuo, e queste domande sono generalmente utili per far sentire il candidato rilassato e a suo agio e avviare discussioni casuali.
In generale, le risposte a queste domande potrebbero essere come: ti piace leggere un genere particolare, ti piace la musica, hai ricevuto qualche premio per alcune attività di volontariato / filantropia, ecc. Inoltre, queste domande sono generalmente poste nel round delle risorse umane (e meno probabile che venga richiesto da una persona tecnica).
D # 22) Quanto tempo sei disposto a dedicare all'apprendimento proattivo di nuovi strumenti e tecnologie?
Risposta: Qui l'intervistatore valuta la tua disponibilità a imparare cose nuove se ti viene lanciato qualcosa di insolito o nuovo. Inoltre consente all'intervistatore di sapere che sei proattivo? Sei disposto a investire su te stesso e sulla tua carriera? eccetera.
Quindi, mentre rispondi a tali domande, sii onesto e comprova le tue risposte con esempi - Per esempio, Potresti menzionare che l'anno scorso ti sei presentato per una certificazione Java e ti sei preparato al di fuori del lavoro impiegando alcune ore ogni settimana.
Conclusione
In questo articolo, abbiamo discusso del processo di intervista dell'ingegnere dello sviluppo software nel test e di domande di esempio che vengono generalmente poste dai candidati in diverse organizzazioni e profili. In generale, le interviste SDET sono di natura molto ampia e dipendono molto dall'azienda all'azienda.
Ma i processi di intervista sono simili a ciò che è disponibile per un profilo sviluppatore con una maggiore enfasi sulla qualità e sui framework di automazione.
È importante capire che, al giorno d'oggi, le aziende sono meno concentrate su qualsiasi linguaggio o tecnologia specifica, ma più su un'ampia comprensione dei concetti e sulla capacità di adattarsi agli strumenti / tecnologie richieste dall'azienda.
I migliori auguri per la tua intervista SDET!
Lettura consigliata
- Che cos'è SDET: conoscere la differenza tra Tester e SDET
- Domande e risposte dell'intervista
- Domande e risposte al colloquio di prova ETL
- Alcune domande e risposte sui test manuali complicati
- Domande dell'intervista a Spock con risposte (le più popolari)
- 25 migliori domande e risposte per l'intervista al test agile
- Le 32 migliori domande e risposte per l'intervista di Datastage
- Top 20+ .NET Intervista Domande e risposte