Menú

Preguntes i respostes de l'entrevista SDET (guia completa)

sdet interview questions

Proveu El Nostre Instrument Per Eliminar Problemes

Llegiu aquesta guia completa per a l'enginyer en desenvolupament de programari a les entrevistes de proves per conèixer el format i com respondre les preguntes de l'entrevista SDET que es fan a les diverses rondes:

En aquest tutorial, coneixerem algunes de les preguntes més freqüents de les entrevistes per als rols SDET. També veurem, en general, el patró comú de les entrevistes i compartirem alguns consells per excel·lir en les entrevistes.

Utilitzarem llenguatge Java per als problemes de codificació d’aquest tutorial, tot i que la majoria dels tutorials SDET són agnòstics del llenguatge i els entrevistadors solen ser flexibles pel que fa al llenguatge que el candidat tria utilitzar.

Preguntes i respostes de l

Què aprendreu:

Guia de preparació d’entrevistes SDET

Les entrevistes SDET, en la majoria de les principals empreses de productes, són bastant similars a la manera com es realitzen les entrevistes per a funcions de desenvolupament. Això es deu al fet que es preveu que els SDET també coneguin i entenguin gairebé tot el que el desenvolupador sap.

El que difereix són els criteris segons els quals es jutja l’entrevistat SDET. Els entrevistadors d’aquest rol busquen habilitats de pensament crític, així com si la persona entrevistada té experiència pràctica en codificació i té un ull per a la qualitat i els detalls.

A continuació, es detallen alguns punts en què s’hauria de centrar en gran mesura algú que es prepara per a una entrevista amb SDET:

Ba preguntes per fer en l'entrevista
  • Atès que, la majoria de les vegades, aquestes entrevistes són tecnològiques / agnòstiques del llenguatge, per tant els candidats han d’estar disposats a aprendre noves tecnologies (i aprofitar les habilitats existents) quan sigui necessari.
  • Hauria de tenir bones comunicacions i habilitats en equip, ja que els rols de SDET requereixen actualment comunicació i col·laboració a diversos nivells amb diversos grups d'interès.
  • Hauria de tenir una comprensió bàsica de diferents conceptes de disseny de sistemes, escalabilitat, simultaneïtat, requisits no funcionals, etc.

A les seccions següents, intentarem entendre el format general de l’entrevista juntament amb algunes preguntes de mostra.

Enginyer de desenvolupament de programari en entrevista de prova

La majoria de les empreses tenen el format preferit d’entrevistar candidats per a un rol SDET ja que, de vegades, el rol és molt específic per a un equip i s’espera que la persona s’avaluï com un ajust perfecte per a l’equip al qual es contracta.

Però, el tema de les entrevistes es basa generalment en els punts següents:

  • Discussió telefònica: Conversa amb l'administrador i / o els membres de l'equip que sol ser una ronda de selecció.
  • Ronda escrita: Amb preguntes específiques de test / carcassa de prova.
  • Ronda de competència en codificació: Les preguntes de codificació senzilles (llenguatge agnòstic) i es demana al candidat que escrigui codi a nivell de producció.
  • Comprensió dels conceptes bàsics de desenvolupament: Igual que els conceptes OOPS, els principis SOLID, etc.
  • Disseny i desenvolupament de Test Automation Framework
  • Llenguatges de seqüència: Seleni, Python, Javascript, etc.
  • Discussió i negociacions sobre Cultura Fit / RRHH

Preguntes i respostes de l'entrevista SDET

En aquesta secció, discutirem algunes preguntes de mostra juntament amb respostes detallades, per a les diferents categories que sol·liciten la majoria de companyies de productes que contracten per a funcions SDET.

Competència en codificació

En aquesta ronda, es donen problemes de codificació senzills per escriure en el llenguatge escollit. Aquí, l’entrevistador vol avaluar el domini de les construccions de codificació, així com gestionar aspectes com ara escenaris marginals i comprovacions de nul·la, etc.

De vegades, els entrevistadors també poden demanar que s’escrivin proves unitàries per al programa escrit.

Vegem alguns problemes de mostra.

P # 1) Escriure un programa per canviar 2 números sense utilitzar la 3a variable (temporal)?

Resposta :

Programa per canviar dos números:

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

Aquí teniu la sortida del fragment de codi anterior:

output-swap2nos 8 new 1

Al fragment de codi anterior, és important tenir en compte que, l’entrevistador ha demanat específicament canviar 2 nus sense utilitzar una tercera variable temporal. A més, és important que, abans d’enviar la solució, sempre es recomani passar (o executar en sec) el codi per a almenys 2-3 entrades. Provem de valors positius i negatius.

Valors positius: 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)

Valors negatius: X = -3, I = 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)

P # 2) Escriure un programa per invertir un número?

Resposta: Ara, la declaració del problema pot semblar inicialment intimidant, però sempre és aconsellable demanar-li aclarir preguntes a l’entrevistador (però no molts detalls). Els entrevistadors poden optar per proporcionar consells sobre el problema, però si el candidat fa moltes preguntes, també indica que el candidat no dóna prou temps per entendre bé el problema.

Aquí, el problema espera que un candidat també faci algunes suposicions: per exemple, el nombre podria ser un nombre enter. Si l'entrada és 345, la sortida hauria de ser 543 (que és inversa de 345)

Vegem el fragment de codi d'aquesta solució:

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

Sortida d’aquest programa contra entrada : 10025 - L'esperat seria : 52001

output-reverseNumber 6 new

P # 3) Escriure un programa per calcular la factorial d'un nombre?

Resposta: Factorial és una de les preguntes més freqüents en gairebé totes les entrevistes (incloses les entrevistes amb desenvolupadors)
Per a les entrevistes amb desenvolupadors, es posa més èmfasi en conceptes de programació com ara programació dinàmica, recursivitat, etc., mentre que des de l’enginyer de desenvolupament de programari en perspectiva de prova, és important gestionar els escenaris de vora com ara valors màxims, valors mínims, valors negatius, etc. són importants, però esdevenen secundaris.

Vegem un programa per al factorial mitjançant recursivitat i for-loop amb la manipulació de nombres negatius i que retorna un valor fix de -9999 per als nombres negatius que s’hauria de gestionar al programa que crida la funció factorial.
Consulteu el fragment de codi següent:

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

Vegem la sortida de: factorial mitjançant el bucle, factorial mitjançant recursivitat i factorial d’un nombre negatiu (que retornaria un valor predeterminat de -9999)

sortida-factorial 4 nou

P # 4) Escriure un programa per comprovar si una cadena determinada té parèntesis equilibrats?

Resposta:

Enfocament - Aquest és un problema lleugerament complex, on l’entrevistador busca una mica més que el coneixement de només codificar construccions. Aquí, l’expectativa és pensar i utilitzar l’estructura de dades adequada per al problema que ens ocupa.

Molts de vosaltres us podreu sentir intimidats per aquest tipus de problemes, ja que alguns de vosaltres no els hauríeu sentit i, per tant, encara que siguin simples, poden semblar complexos.

Però generalment per a aquests problemes / preguntes: per exemple, a la pregunta actual, si no sabeu què són els parèntesis equilibrats, podeu preguntar-lo molt bé a l’entrevistador i, després, treballar cap a la solució en lloc de tocar un punt cec.

Vegem com abordar una solució: Després d’entendre què són els parèntesis equilibrats, podeu pensar en utilitzar l’estructura de dades adequada i començar a escriure algorismes (passos) abans de començar a codificar la solució. Moltes vegades, els algoritmes en si mateixos resolen molts escenaris d'avantguarda i donen molta claredat sobre com serà la solució.

Vegem la solució:

Els parèntesis equilibrats han de comprovar si hi ha una cadena que conté parèntesis (o claudàtors), ha de tenir un recompte d’obertura i tancament iguals i una estructura posicional ben estructurada. Per al context d’aquest problema, utilitzarem parèntesis equilibrats ja que - ‘()’, ‘()’, ‘{}’ - és a dir, una cadena determinada pot tenir qualsevol combinació d’aquests claudàtors.

Tingueu en compte que abans d’intentar el problema, és bo aclarir si la cadena només contindrà els caràcters entre claudàtors o qualsevol número, etc. (ja que això pot canviar una mica la lògica)

Exemple: Una cadena determinada - '{() {} ()} - és una cadena equilibrada ja que està estructurada i no té parèntesis de tancament i obertura iguals, però cadena -' {(}) {} () '- aquesta cadena, tot i que té un nombre igual de parèntesis d'obertura i tancament, però encara no està equilibrat perquè podeu veure que sense un tancament '(' hem tancat '} '(és a dir, tots els claudàtors interiors haurien de tancar-se abans de tancar un claudàtori exterior)

Utilitzarem una estructura de dades de pila per resoldre aquest problema. Si voleu saber més sobre els conceptes bàsics de la pila, consulteu aquí

Una pila és una estructura de dades LIFO (tipus Last In First Out), penseu en això com una pila / pila de plaques en un casament; recollireu la placa més alta sempre que la feu servir.

Algorisme:

# 1) Declareu una pila de caràcters (que contindria els caràcters de la cadena i, depenent d’una certa lògica, traieu i traieu els caràcters).

# 2) Travesseu la cadena d'entrada i sempre que vulgueu

  • Hi ha un caràcter de claudàtors que s’obre, és a dir, ‘(‘, {’o‘ (‘- empènyer el personatge a Stack.
  • Hi ha un caràcter de tancament (és a dir, ')', '}', ')': apareix un element de Stack i comprova si coincideix amb el contrari del caràcter de tancament, és a dir, si el caràcter és '}', llavors a Stack pop hauries d'esperar ' {'
    • Si l'element emergent no coincideix amb els parèntesis de tancament, la cadena no està equilibrada i podeu retornar resultats.
    • En cas contrari, continueu amb l'enfocament push and pop de la pila (aneu al pas 2).
  • Si la cadena es travessa completament i la mida de la pila també és zero, podem dir / inferir que la cadena donada és una cadena de parèntesis equilibrada.

En aquest punt, és possible que també vulgueu discutir l'enfocament de la solució que teniu com a algorisme i assegurar-vos que l'entrevistador estigui d'acord amb l'enfocament.

Codi:

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

La sortida del fragment de codi anterior:

output-balanceParantheses 2 new

Igual que ho vam fer per als nostres problemes de codificació anteriors, sempre és bo executar el codi amb almenys 1-2 entrades vàlides, així com amb 1-2 entrades no vàlides i assegurar-se que tots els casos es gestionen adequadament.

NOTA: Sempre és bo pensar la solució en veu alta (i no només dins de la ment) i, sorprenentment, aquest és un tret important que busquen els entrevistadors. Molts entrevistadors podrien acabar amb l'algorisme i passar a la següent afirmació del problema.

A la solució de codificació anterior, per a l’entrevista amb el desenvolupador, l’entrevistador pot demanar resoldre-ho utilitzant matrius en lloc d’apilar directament (és a dir, fent servir matriu com a pila), però, en general, es tracta més de ser conceptualment clar i capaç de manejar totes les entrades no vàlides.

Test Automation Framework relacionat

Aquesta secció de l'entrevista és més específica sobre les responsabilitats de proves i SDET. Espereu preguntes relacionades amb el disseny i el desenvolupament del marc d’automatització, els pros i els contres de l’ús de diferents enfocaments, etc.

Vegem algunes mostres de preguntes i solucions per al mateix.

Q # 5) Explicar i dissenyar components del marc d'automatització d'una aplicació web?

Resposta: Aquesta pregunta és una mica subjectiva i l’entrevistador pretén avaluar quant sap el candidat sobre el disseny i desenvolupament del marc. La resposta a aquesta pregunta ajuda l’entrevistador a entendre si el candidat pot crear o crear marcs personalitzats des de zero.
Vegem un parell de punts que us ajudarien a estructurar la solució per a aquesta pregunta:

  • Podeu parlar de diferents tipus de marcs, com ara: basat en dades, basat en paraules clau i marc híbrid.
  • Model d'objectes de pàgina per emmagatzemar detalls de diversos elements en diferents pàgines / mòduls de l'aplicació web.
  • Mòduls habituals com funcions d’ajuda, utilitats, registradors, etc.
  • Mòduls d'informes com generar informes d'execució de proves, integrar informes amb el correu electrònic i programar l'execució de proves, etc.

Lectura recomanada => Marcs d'automatització de proves més populars

P # 6) Expliqueu les estratègies de prova per a una aplicació mòbil?

Resposta: Aquestes preguntes se solen fer en funció del paper. Si el paper és principalment treballar en aplicacions mòbils, la qüestió tindrà més rellevància. Podeu parlar des de la vostra experiència si heu planejat proves mòbils com a part de les funcions actuals o anteriors.

Alguns indicadors per estructurar la resposta a aquesta pregunta podrien ser:

  • Proves en dispositius i emuladors.
  • Identificar i emmagatzemar objectes / elements en diferents pantalles - Exemple: Model d'objectes de pàgina.
  • Prova de càrrega d'una aplicació mòbil.
  • Podeu parlar de diferents tipus d'aplicacions mòbils, com ara aplicacions natives, aplicacions híbrides, i discutir estratègies / enfocaments que faríeu servir per provar-les.

Lectura recomanada => Tutorials de proves d'aplicacions mòbils

Q # 7) Dissenyar un marc d'automatització per provar les API REST?

Resposta: Aquesta és de nou una pregunta subjectiva i podeu fer preguntes aclaridores si l'entrevistador vol que desenvolupeu un marc per provar el comportament funcional de l'API o requisits no funcionals, com ara les proves de càrrega / rendiment.

Podeu començar la vostra resposta cobrint els punts següents:

  • Components del framework d'automatització d'API com ara Configuració local, Configuració simulada de l'API o Proves d'API allotjades.
  • Eines utilitzades per a l'automatització d'API. Hi ha diverses eines disponibles per a validar els aspectes funcionals d'una API basada en REST. Algunes d’aquestes eines són Postman, Rest Assured, etc. Per obtenir informació detallada sobre diferents eines, podeu consultar el nostre article aquí .
  • Automatització no funcional de les API.
  • Execució programada de proves d'automatització.
  • Integració de proves d'automatització d'APIs.

Q # 8) Preguntes específiques del marc.

Resposta: De vegades, segons el perfil entrevistat, pot haver-hi un requisit perquè un candidat sigui competent amb un determinat marc, per exemple. Seleni, JMeter, etc.

Lectura recomanada => Carter , Mockito , Flux d’especificacions , Seleni , JMeter

Proves relacionades

Tot i que poques vegades, però depèn del perfil, pot haver-hi preguntes sobre pràctiques, termes i tecnologies generals de proves, com ara la gravetat d’errors, la prioritat, la planificació de proves, la caixa de proves, etc. Es preveu que un SDET conegui tots els conceptes de proves manuals i que sigui familiar amb les terminologies importants.

En aquesta secció, podeu esperar preguntes com aquestes:

P # 9) Quins són els diferents components d'un pla de proves?

Resposta: En general, se'ls demana que validin els conceptes bàsics de prova i la mentalitat. Aquests termes i documents són una cosa que tots els controladors de qualitat manuals i els SDET d'automatització haurien de conèixer.
Aquí podeu parlar de diversos components del pla de prova, com ara:

  • Criteris d’entrada i sortida
  • Abast: Comenteu les funcions de prova que estan a l'abast i què s'automatitzaria: només es tractarà de funcions funcionals o de requisits no funcionals, com ara escalabilitat, rendiment, etc.
  • Línies de temps
  • Eines a utilitzar
  • Assignació de recursos, etc.

Lectura recomanada => Com escriure un bon pla de proves

P # 10) Què defineix i decideix la prioritat i la gravetat d’un error?

Resposta: La prioritat i la gravetat dels defectes es poden explicar fàcilment amb ajuda d’exemples. Suposem que una característica com ara registrar-se està trencada i impedeix que els usuaris accedeixin a l’aplicació; aleshores és un problema d’alta prioritat i severitat. De la mateixa manera, hi pot haver exemples de defectes de baixa gravetat / alta prioritat i diverses altres combinacions.

En general,

  • Prioritat significa la importància del problema.
  • Gravetat significa l’impacte que té el problema per al client o l’usuari de l’aplicació.

Lectura recomanada => Prioritat i gravetat dels defectes

Q # 11) Què és el particionament d'equivalència? Il·lustrar amb un exemple.

Resposta: El particionament d'equivalència és una tècnica que s'utilitza principalment per a proves de caixes negres, per provar diverses combinacions d'entrades amb un camp determinat.

Per exemple, si proveu una aplicació comercial i voleu escriure tots els escenaris de prova per al camp 'Quantitat': quines serien les diferents entrades que provareu per a aquest camp?
Atès que el requisit funcional és que la quantitat ha de ser un valor enter positiu entre 1 i 100000. Per tant, per provar diverses entrades (vàlides i no vàlides), podeu fer proves per a 1 entrada de cada categoria.

  • Valors vàlids: Entre 1 i 100000 -> prova de qualsevol valor vàlid x tal que x> 1 i x<100000.
  • Valors límit: Proveu els valors límit permesos, és a dir, 1 i 100000.
  • Valors no vàlids: Valors que es troben fora de l'interval permès, és a dir, proveu un valor d'aquest tipus per a x, tal que x 100000.

Lectura recomanada => Estratègia de repartiment d'equivalències

Disseny del sistema relacionat

Les preguntes sobre el disseny del sistema solen ser més adequades per a entrevistes amb desenvolupadors, on es considera que un desenvolupador té una comprensió àmplia de diferents conceptes generals, com ara l’escalabilitat, la disponibilitat, la tolerància a fallades, la selecció de bases de dades, el threading, etc. En poques paraules, haureu d’utilitzar experiència i coneixement de sistemes per respondre a aquestes preguntes.

Però és possible que tingueu la sensació que un sistema que necessita anys d’experiència i centenars de desenvolupadors per codificar, com podria una persona respondre a la pregunta en uns 45 minuts?

La resposta és: Aquí l’expectativa és jutjar la comprensió del candidat i l’ampli espectre de coneixement que pot aplicar tot resolent problemes complexos.

Avui en dia, aquestes preguntes també es comencen a llançar a les entrevistes SDET. Aquí l’expectativa continua sent la mateixa que la de l’entrevista amb el desenvolupador, però amb criteris de judici relaxats i, principalment, una ronda d’elevació de barres on, segons la resposta del candidat, es pot considerar un candidat per al següent nivell o passar a un nivell inferior.

En general, per a preguntes d’entrevistes de disseny de sistemes, el candidat hauria de conèixer els conceptes següents

  1. Conceptes bàsics dels sistemes operatius: Paginació, sistemes de fitxers, memòria virtual i memòria física, etc.
  2. Conceptes de xarxes: Comunicació HTTP, pila TCP / IP, topologies de xarxa.
  3. Conceptes d’escalabilitat: Escala horitzontal i vertical.
  4. Conceptes de simultaneïtat / roscat
  5. Tipus de base de dades: Bases de dades SQL / sense SQL, quan s’ha d’utilitzar quin tipus de base de dades, avantatges i desavantatges dels diferents tipus de bases de dades.
  6. Tècniques de hash
  7. Comprensió bàsica de CAP teorema, fragmentació, partició, etc.

Vegem algunes preguntes de mostra

P # 12) Dissenyeu un sistema d’escurçament d’URL com un URL minúscul ?

Resposta: És possible que molts candidats ni tan sols coneguin els sistemes d’escurçament d’URL en general. En aquest cas, està bé preguntar a l’entrevistador sobre la declaració del problema en lloc de capbussar-se sense entendre’l.

Abans de respondre a aquestes preguntes, els candidats haurien d’estructurar la solució i escriure punts, i després començar a discutir la solució amb l’entrevistador.

Analitzem breument la solució

a) Aclarir els requisits funcionals i no funcionals

Requisits funcionals: El requisit funcional és simplement des de la perspectiva del client, és un sistema que s’alimenta d’un URL gran (llarg) i la sortida ha de ser un URL abreujat.

Quan s’accedeix a l’URL escurçat, hauria de redirigir l’usuari a l’URL original. Per exemple - proveu d’escurçar un URL real a la pàgina web https://tinyurl.com/, introduïu un URL d’entrada com www.softwaretestinghelp.com i hauríeu d’obtenir un URL petit com https://tinyurl.com/shclcqa

Requisits no funcionals: El sistema hauria de ser performant en termes de redirecció amb latència de mil·lisegons (ja que és un salt addicional per a un usuari que accedeixi a l'URL original).

  • Els URL reduïts han de tenir un temps de caducitat configurable.
  • Els URL reduïts no haurien de ser previsibles.

b) Estimació de capacitat / trànsit

Això és molt important des de la perspectiva de totes les preguntes sobre el disseny del sistema. L’estimació de capacitat determina essencialment la càrrega esperada que obtindrà el sistema. Sempre és bo començar amb una suposició i discutir amb l’entrevistador. Això també és important des de la perspectiva de la planificació del dimensionament de la base de dades, tant si el sistema és pesat com a llegit o pesat en escriptura, etc.

Fem alguns números de capacitat per a l'exemple de reductor d'URL.

Suposem que hi haurà 100.000 sol·licituds noves d’escurçament d’URL al dia (amb una proporció de lectura-escriptura 100: 1, és a dir, per cada 1 URL escurçada, tindrem 100 sol·licituds de lectura contra l’URL escurçat)

Així tindrem,

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

c) Consideracions sobre emmagatzematge i memòria

Després dels números de capacitat, podem extrapolar aquests números per obtenir,

  • La capacitat d'emmagatzematge necessària per adaptar-se a la càrrega esperada, Per exemple, podem planejar dissenyar una solució d’emmagatzematge que admeti les sol·licituds fins a un any.
    Exemple: Si cada URL escurçat consumeix 50 bytes, les dades / emmagatzematge total que requeriríem durant un any serien:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
  • Les consideracions de memòria són importants per planificar el sistema des de la perspectiva del lector. és a dir, per a sistemes que pesen la lectura, com ara el que estem intentant crear (perquè l’URL es crearia una vegada però s’hi accediria diverses vegades).
    Els sistemes de lectura pesada solen utilitzar la memòria cau per ser més performants i evitar la lectura des de l’emmagatzematge permanent per estalviar en E / S de lectura.

Suposem que volem emmagatzemar el 60% de les nostres sol·licituds de lectura a la memòria cau, de manera que al llarg de l'any requeriríem el 60% del total de lectures durant l'any x bytes requerits per cada entrada

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

Per tant, segons els nostres números de capacitat, aquest sistema requeriria aproximadament 1 GB de memòria física

d) Estimacions d'ample de banda

Es requereixen estimacions d’amplada de banda per analitzar la velocitat de lectura i escriptura en bytes que caldria per realitzar un sistema. Fem estimacions en relació amb els nombres de capacitat que hem pres.

Exemple: Si cada URL abreujat consumeix 50 bytes, les velocitats totals de lectura i escriptura que necessitaríem serien les següents:

WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s

e) Disseny i algorisme de sistemes
Aquesta és essencialment la principal lògica o algorisme de negoci que s’utilitzaria per complir els requisits funcionals. En aquest cas, volem generar URL escurçats únics per a un URL determinat.

Els diferents enfocaments que es podrien utilitzar per generar URL reduïts són:

Hashing: Podem pensar en generar URL reduïts creant un hash de l’URL d’entrada i assignant la clau hash com a URL reduïda.

Hashing

Aquest enfocament pot tenir alguns problemes quan hi ha diferents usuaris del servei i, si introdueixen el mateix URL, es traduiria en obtenir el mateix URL abreujat.

Cadenes escurçades precreadesi assignat a URL quan es crida el servei: Un altre enfocament pot ser retornar una cadena escurçada predefinida de l'agrupació de cadenes ja generades.

Cadenes escurçades precreades

API de servei: Podem pensar en el sistema d’escurçador d’URL com un conjunt d’APIs basades en REST que tenen els extrems següents:

  • createUrl (URL de cadena, data i hora de caducitat): Aquest punt final crea i retorna un URL abreujat amb la durada de caducitat definida tal com s’especifica a l’entrada.
  • retrieveUrl (String shortenedUrl): Aquest punt final recupera l'URL que es redirigeix ​​a l'URL escurçat indicat.

f) Escalat i simultaneïtat

L’escala és una consideració important des d’una perspectiva de requisits no funcionals.

Es tracta de, com pot el sistema

  • Escala sota càrrega: El sistema hauria de poder escalar amb gràcia sota càrrega i no deixar de funcionar després que es produeixi un augment inesperat de la càrrega.

Lectura recomanada => Tècniques d’escala

  • Quin rendiment pot tenir el sistema, per exemple: si el sistema s’utilitza amb capacitat sostinguda durant molt de temps, el rendiment del sistema es degradaria o es mantindria estable?

Hi pot haver moltes preguntes diferents sobre el disseny del sistema, com ara a continuació, però, en general, totes elles posarien a prova la comprensió més àmplia dels diferents conceptes dels candidats que hem comentat a la solució del sistema d’escurçament d’URL.

Q # 13) Dissenyeu una plataforma de vídeo com Youtube.

Resposta: Aquesta pregunta també es pot abordar, de manera similar a la que hem comentat anteriorment sobre la pregunta de TinyUrl (i això s'aplica a gairebé totes les preguntes de l'entrevista de disseny de sistemes). L'únic factor diferencial seria mirar / detallar el sistema que voleu dissenyar.

Per a Youtube, tots sabem que és una aplicació de transmissió de vídeo i té moltes funcions, com permetre a un usuari penjar vídeos nous, emetre transmissions web en directe, etc. Per tant, durant el disseny del sistema, heu d’aplicar els components de disseny del sistema necessaris. En aquest cas, és possible que hàgim d'afegir components relacionats amb les funcions de transmissió de vídeo.

Podeu discutir punts com:

  • Emmagatzematge: Quin tipus de base de dades escolliríeu per emmagatzemar contingut de vídeo, perfils d'usuaris, llistes de reproducció, etc.?
  • Seguretat i autenticació / autorització
  • Memòria cau: Com que una plataforma de transmissió com YouTube hauria de ser performant, la memòria cau és un factor important per dissenyar qualsevol sistema d’aquest tipus.
  • Concurrència: Quants usuaris poden transmetre vídeo en paral·lel?
  • Altres funcionalitats de la plataforma, com ara el servei de recomanació de vídeos, que recomana / suggereix als usuaris els propers vídeos que poden veure, etc.

Q # 14) Dissenyeu un sistema eficient per operar 6 ascensors i assegureu-vos que una persona ha d'esperar un temps mínim mentre espera que arribi l'ascensor ?

Resposta: Aquest tipus de preguntes sobre disseny de sistemes tenen un nivell més baix i esperarien que el candidat pensés primer en el sistema d'ascensors i enumerés totes les funcions possibles que cal donar suport i dissenyar / crear classes i relacions / esquemes de base de dades com a solució.

Des de la perspectiva de SDET, l’entrevistador només esperaria les classes principals que creieu que tindria la vostra aplicació o sistema i les funcionalitats bàsiques es gestionarien amb la solució suggerida.

Vegem diverses funcions del sistema d'ascensors que s'esperarien

Podeu fer preguntes aclaridores com ara

  • Quantes plantes hi ha?
  • Quants ascensors hi ha?
  • Tots els ascensors són ascensors de servei / passatgers?
  • Estan configurats tots els ascensors per aturar-se a cada pis?

A continuació, es detallen els diferents casos d’ús aplicables a un sistema d’ascensors simple:

sistema-disseny-sistema_elevador

En termes de classes / objectes bàsics d’aquest sistema, podeu considerar tenir:

  • Usuari: Tracta de totes les propietats d’un usuari i de les accions que pot fer sobre Elevator Object.
  • Ascensor: Elevador Propietats específiques com alçada, amplada, número_elevador_elevador.
  • Porta de l'ascensor: Totes les coses relacionades amb la porta, com ara no hi ha portes, tipus de porta, automàtica o manual, etc.
  • Control_botó_elevador: Hi ha diferents botons / controls disponibles a l'ascensor i diferents estats en què es poden trobar.

Un cop hàgiu acabat, dissenyant classes i les seves relacions, podeu parlar de configurar esquemes de base de dades.

Un altre component important del sistema Elevator és el sistema Eventing. Podeu parlar sobre la implementació de cues o en una configuració més complexa de creació de fluxos d’esdeveniments mitjançant Apache Kafka, on els esdeveniments es lliuren als sistemes respectius perquè s’actuï.

El sistema d'esdeveniments és un aspecte important, ja que hi ha diversos usuaris (en plantes diferents) que utilitzen l'ascensor alhora. Per tant, les sol·licituds de l’usuari s’han de posar en cua i servir-les segons la lògica configurada als controladors Elevator.

P # 15) Dissenyar Instagram / Twitter / Facebook.

Resposta: Totes aquestes plataformes estan relacionades en certa manera, ja que permeten als usuaris connectar-se d’una manera o altra i compartir coses mitjançant diferents tipus de suports, com ara missatges / vídeos i xats.

Per tant, per a aquest tipus d’aplicacions o plataformes de xarxes socials, hauríeu d’incloure punts a continuació mentre discutiu sobre el disseny d’aquests sistemes (a més del que hem comentat per al disseny del sistema d’escurçador d’URL):

  • Estimació de capacitat: La majoria d’aquests sistemes serien molt pesats, de manera que cal una estimació de capacitat i ens permetria assegurar-nos que s’assegura la configuració adequada del servidor i de la base de dades per atendre la càrrega necessària.
  • Esquema de bases de dades: Els principals esquemes de base de dades importants que s’han de discutir són: detalls d’usuari, relacions d’usuari, esquemes de missatges, esquemes de contingut.
  • Servidors d'allotjament de vídeo i imatges: La majoria d’aquestes aplicacions tenen vídeos i imatges compartides entre usuaris. Per tant, els servidors d’allotjament de vídeo i imatges s’han de configurar segons les necessitats.
  • Seguretat: Totes aquestes aplicacions haurien de garantir un alt nivell de seguretat a causa de la informació de l’usuari / informació d’identificació personal dels usuaris que emmagatzemen. Qualsevol intent de pirateria, SQL Injection no hauria de tenir èxit en aquestes plataformes, ja que podria costar la pèrdua de dades de milions de clients.

Problemes basats en escenaris

Els problemes basats en l’escenari solen ser per a gent de nivell superior, on es donen diferents escenaris en temps real i es pregunta al candidat la seva manera de manejar aquesta situació.

P # 16) Atès que s'ha de publicar una revisió crítica el més aviat possible: quin tipus d'estratègia de prova tindríeu?

Resposta: Ara, aquí l’entrevistador vol entendre essencialment

  • Com i quin tipus d’estratègies de prova podeu pensar?
  • Quina cobertura faríeu per a una revisió?
  • Com validaríeu la revisió posterior al desplegament? etc.

Per respondre a aquestes preguntes, es podria utilitzar situacions de la vida real si es pogués relacionar amb el problema. També heu d’esmentar que sense les proves adequades, no estareu disposat a lliurar cap codi a la producció.

Per a les correccions crítiques, sempre heu de treballar junt amb el desenvolupador i provar d’entendre quines àrees podria afectar i preparar un entorn que no sigui de producció per replicar l’escenari i provar-ne la solució.

Aquí també és important esmentar que continuareu supervisant la correcció (mitjançant eines de control, taulers, registres, etc.) després del desplegament per veure qualsevol comportament anormal a l’entorn de producció i assegurar-vos que no hi hagi cap impacte negatiu de la correcció que sigui fet.

També hi pot haver altres preguntes, que són sobretot per entendre la perspectiva del candidat sobre les proves d'automatització, els terminis de lliurament, etc. (i aquestes preguntes poden variar d'empresa a empresa, així com l'antiguitat del rol. En general, aquestes preguntes es fan per a nivells d'antiguitat / lideratge rols)

P # 17) Sacrificaria les proves completes per llançar un producte ràpidament?

Resposta: Aquestes preguntes solen implicar que l’entrevistador entengui els seus pensaments des d’una perspectiva de lideratge i quines són les coses amb les quals es comprometria i estaria disposat a llançar un producte buggy en lloc de menys temps.

Les respostes a aquestes preguntes s’han de contrastar amb les experiències reals del candidat.

Per exemple, es podria esmentar que, en el passat, calia fer una trucada per llançar una revisió, però no es va poder provar a causa de la no disponibilitat de l'entorn d'integració. Per tant, l’heu llançat de manera controlada: desplegant-lo a un percentatge més reduït, després heu supervisat els registres / esdeveniments i després heu iniciat el llançament complet, etc.

P # 18) Com crearíeu l'estratègia d'automatització per a un producte que no tingui cap prova d'automatització?

Resposta: Aquest tipus de preguntes són obertes i generalment són un bon lloc per prendre la discussió de la manera que vulgueu. També podeu mostrar les vostres competències, coneixements i àrees tecnològiques que són el vostre punt fort.

Per exemple, per respondre a aquest tipus de preguntes, podeu citar exemples de l'estratègia d'automatització que vau adoptar mentre construíeu un producte en la vostra funció anterior.

Per exemple, podeu esmentar punts com:

  • Com que el producte requeria iniciar l’automatització des de zero, teniu prou temps per pensar i dissenyar un marc d’automatització adequat triant un llenguatge / tecnologia que la majoria de la gent tingués el coneixement per evitar introduir una nova eina i aprofitar el coneixement existent.
  • Va començar automatitzant els escenaris funcionals més bàsics que es consideraven P1 (sense els quals no es podria passar cap versió).
  • També heu pensat a provar el rendiment i l’escalabilitat del sistema mitjançant eines de prova automatitzades com JMETER, LoadRunner, etc.
  • Heu pensat en automatitzar els aspectes de seguretat de l'aplicació tal com s'indica a la carpeta OWASP Normes de seguretat.
  • Heu integrat les proves automatitzades a la canalització de compilació per obtenir informació primerenca, etc.

Equip Fit i Culture Fit

Aquesta ronda depèn generalment d’empresa a empresa. Però la necessitat / necessitat d’aquesta ronda és entendre el candidat des de la perspectiva de la cultura de l’equip i l’organització. L’objectiu d’aquestes preguntes també és entendre la personalitat del candidat i el seu enfocament cap a la feina / persones, etc.

En general, els responsables de recursos humans i contractació són els que fan aquesta ronda.

Les preguntes que solen aparèixer durant aquesta ronda són les següents:

P # 19) Com es resolen els conflictes dins del seu rol actual?

Resposta: Aquí teniu una explicació addicional: suposem que teniu un conflicte amb el cap o els membres de l'equip immediat, quins són els passos que heu de fer per resoldre aquests conflictes?

Per a aquest tipus de preguntes, justifiqueu tot el que pugueu amb exemples reals que podrien haver passat a la vostra carrera en organitzacions actuals o anteriors.

Es poden esmentar coses com:

  • Voleu resoldre els conflictes el més aviat possible que es produeixin per motius professionals (i no voldríeu afectar les vostres relacions personals a causa d’aquests).
  • Es pot esmentar que en general intenteu comunicar-vos de manera eficaç i parlar / discutir amb la persona individualment per resoldre qualsevol diferència / problema.
  • Es pot esmentar que si les coses comencen a empitjorar, es recorrerà a l'ajuda d'una persona major o del seu gerent per obtenir les seves aportacions.

A continuació es mostren altres exemples de qüestions d’ajust a l’equip / cultura (a la majoria s’han de respondre en un enfocament similar que hem comentat per a la pregunta anterior. Parlar d’escenaris de la vida real és una clau aquí, ja que l’entrevistador pot relacionar-ho d’una manera millor bé.

P # 20) Quin tipus de conciliació laboral i personal esperes del nou rol per al qual es considera contractat?

Resposta: Atès que el gerent de contractació és algú que sap el que exigeix ​​el rol, quant esforç addicional es pot requerir de vegades, de manera que, en general, l’entrevistador intenta mesurar si les vostres expectatives són radicalment diferents del que espera el paper.

Suposem que ho dius que no preferiu assistir a reunions nocturnes i que el paper espera que tingueu una col·laboració important entre un equip que es troba en una zona horària diferent, llavors l’entrevistador pot iniciar un debat sobre el que aquestes són les expectatives del paper. adaptar-se? etc.

Un cop més, es tracta d’una conversa més casual, però des de la perspectiva de l’entrevistador, volen entendre les vostres expectatives per avaluar la vostra candidatura per al lloc per al qual s’entrevista.

P # 21) A part de la feina, quines són les vostres aficions?

Resposta: Aquestes preguntes són purament subjectives i específiques per a cada individu, i aquestes preguntes solen ser útils per fer que el candidat se senti relaxat i fàcil i iniciar discussions casuals.

En general, les respostes a aquestes preguntes poden ser com ara: t’agrada llegir un gènere en concret, t’agrada la música, has rebut algun premi per alguna activitat voluntària / de filantropia, etc. A més, aquestes preguntes generalment es fan a la ronda de recursos humans (i menys probable que ho demani una persona tècnica).

P # 22) Quant de temps esteu disposat a dedicar a l’aprenentatge de noves eines i tecnologies de manera proactiva?

Resposta: Aquí l’entrevistador avalua la vostra voluntat d’aprendre coses noves si us llança alguna cosa inusual o nova. També permet a l'entrevistador saber que sou proactiu? Esteu disposat a invertir en vosaltres mateixos i en la vostra carrera? etc.

Per tant, mentre responeu aquestes preguntes: sigueu honestos i justifiqueu les vostres respostes amb exemples. Per exemple, Podríeu esmentar que vau presentar-vos a la certificació Java l’any passat i us heu preparat fora de la feina prenent unes hores cada setmana.

Conclusió

En aquest article, hem debatut sobre l’enginyer de desenvolupament de programari en el procés d’entrevistes de proves i es mostren preguntes que generalment es fan als candidats de diferents organitzacions i perfils. En general, les entrevistes amb SDET tenen una naturalesa molt àmplia i depenen molt d’una empresa a l’altra.

Però els processos d’entrevistes són similars al que hi ha per a un perfil de desenvolupador amb un èmfasi més gran en els marcs de qualitat i automatització.

És important entendre que, actualment, les empreses estan menys centrades en qualsevol llenguatge o tecnologia específics, però més en una comprensió àmplia dels conceptes i de la capacitat d’adaptació a les eines / tecnologies requerides per l’empresa.

Els millors desitjos per a la vostra entrevista SDET.

Lectura recomanada

^