sdet interview questions
Lea esta guía completa para el ingeniero de desarrollo de software en entrevistas de prueba para conocer el formato y cómo responder las preguntas de la entrevista SDET formuladas en las distintas rondas:
En este tutorial, aprenderemos sobre algunas preguntas de entrevistas frecuentes para los roles de SDET. También veremos, en general, el patrón común de las entrevistas y compartiremos algunos consejos para sobresalir en las entrevistas.
Usaremos el lenguaje Java para los problemas de codificación de este tutorial, sin embargo, la mayoría de los tutoriales de SDET son independientes del idioma y los entrevistadores son generalmente flexibles en torno al lenguaje que el candidato elige usar.
Lo que vas a aprender:
Guía de preparación de la entrevista SDET
Las entrevistas SDET, en la mayoría de las principales empresas de productos, son bastante similares a la forma en que se realizan las entrevistas para los roles de desarrollo. Esto se debe a que también se espera que los SDET sepan y comprendan en general casi todo lo que sabe el desarrollador.
Lo que difiere son los criterios según los cuales se juzga al entrevistado SDET. Los entrevistadores para este puesto buscan habilidades de pensamiento crítico, así como si la persona entrevistada tiene experiencia práctica en codificación y tiene buen ojo para la calidad y los detalles.
Aquí hay algunos puntos en los que alguien que se prepara para una entrevista SDET debería enfocarse en gran medida:
diferencia entre las pruebas de caja blanca y caja negra
- Dado que, la mayoría de las veces, estas entrevistas son independientes de la tecnología / el idioma, los candidatos deben estar dispuestos a aprender nuevas tecnologías (y aprovechar las habilidades existentes) cuando sea necesario.
- Debe tener buena comunicación y habilidades de equipo, ya que los roles de SDET en estos días requieren comunicación y colaboración en varios niveles con múltiples partes interesadas.
- Debe tener un conocimiento básico de los diferentes conceptos de diseño de sistemas, escalabilidad, concurrencia, requisitos no funcionales, etc.
En las secciones siguientes, intentaremos comprender el formato general de la entrevista junto con algunos ejemplos de preguntas.
Formato del ingeniero de desarrollo de software en la entrevista de prueba
La mayoría de las empresas tienen su formato preferido para entrevistar a los candidatos para un puesto de SDET, ya que a veces el papel es muy específico para un equipo y se espera que la persona sea evaluada como una persona que encaja perfectamente con el equipo para el que se está contratando.
Pero, el tema de las entrevistas generalmente se basa en los siguientes puntos:
- Discusión telefónica: Conversación con el gerente y / o miembros del equipo que suele ser una ronda de proyección.
- Ronda escrita: Con test / case test de preguntas específicas.
- Ronda de competencia en codificación: Preguntas de codificación simples (independientes del lenguaje) y se le pide al candidato que escriba código de nivel de producción.
- Comprensión de los conceptos básicos de desarrollo: Como conceptos de OOPS, principios SOLID, etc.
- Diseño y desarrollo del marco de automatización de pruebas
- Lenguajes de secuencias de comandos: Selenio, Python, Javascript, etc.
- Discusión y negociaciones de Culture Fit / HR
Preguntas y respuestas de la entrevista SDET
En esta sección, analizaremos algunos ejemplos de preguntas junto con respuestas detalladas, para las diferentes categorías que plantean la mayoría de las empresas de productos que contratan para puestos de SDET.
Competencia en codificación
En esta ronda, se dan problemas de codificación sencillos para escribir en el idioma de su elección. Aquí, el entrevistador quiere medir la competencia con las construcciones de codificación, así como manejar cosas como escenarios de borde y verificaciones nulas, etc.
Ocasionalmente, los entrevistadores también pueden solicitar que se anoten las pruebas unitarias para el programa escrito.
Veamos algunos problemas de muestra.
P # 1) ¿Escribe un programa para intercambiar 2 números sin usar la tercera variable (temporal)?
Responder :
Programa para intercambiar dos números:
|_+_|Aquí está el resultado del fragmento de código anterior:
En el fragmento de código anterior, es importante tener en cuenta que el entrevistador ha solicitado específicamente intercambiar 2 números sin utilizar una tercera variable temporal. Además, es importante que antes de enviar la solución, siempre se recomienda revisar (o ejecutar en seco) el código para al menos 2-3 entradas. Intentemos con valores positivos y negativos.
Valores positivos: X = 2, Y = 3
|_+_|Valores negativos: X= -3, Y= 5
|_+_|Q # 2) ¿Escribe un programa para invertir un número?
Responder: Ahora bien, la declaración del problema puede parecer intimidante al principio, pero siempre es aconsejable preguntar al entrevistador para aclarar las preguntas (pero no muchos detalles). Los entrevistadores pueden optar por dar pistas sobre el problema, pero si el candidato hace muchas preguntas, también indica que el candidato no le da suficiente tiempo para comprender bien el problema.
Aquí, el problema espera que un candidato también haga algunas suposiciones: por ejemplo, el número puede ser un número entero. Si la entrada es 345, la salida debería ser 543 (que es inversa a 345)
Veamos el fragmento de código de esta solución:
|_+_|Salida para este programa contra entrada : 10025 – Esperado sería : 52001
Q # 3) ¿Escribe un programa para calcular el factorial de un número?
Responder: Factorial es una de las preguntas más frecuentes en casi todas las entrevistas (incluidas las entrevistas con los desarrolladores)
Para las entrevistas con desarrolladores, se centra más en conceptos de programación como programación dinámica, recursividad, etc., mientras que desde el ingeniero de desarrollo de software en la perspectiva de prueba, es importante manejar los escenarios de borde como valores máximos, valores mínimos, valores negativos, etc. y enfoque / eficiencia. son importantes pero se vuelven secundarios.
Veamos un programa para factorial que usa recursividad y for-loop con el manejo de números negativos y devolviendo un valor fijo de digamos -9999 para números negativos que deben manejarse en el programa que llama a la función factorial.
Consulte el fragmento de código a continuación:
Veamos la salida para: factorial usando el bucle, factorial usando recursividad y factorial de un número negativo (que devolvería un valor predeterminado establecido de -9999)
P # 4) ¿Escribe un programa para verificar si una cadena dada tiene paréntesis balanceados?
Responder:
Acercarse - Este es un problema un poco complejo, en el que el entrevistador busca algo más que el conocimiento de los constructos de codificación. Aquí, la expectativa es pensar y utilizar la estructura de datos adecuada para el problema en cuestión.
Muchos de ustedes pueden sentirse intimidados por este tipo de problemas, ya que algunos de ustedes quizás no los hayan escuchado y, por lo tanto, incluso si son simples, pueden parecer complejos.
Pero generalmente para tales problemas / preguntas: por ejemplo, En la pregunta actual, si no sabe qué son los paréntesis equilibrados, puede preguntarle al entrevistador y luego trabajar hacia la solución en lugar de dar con un punto ciego.
Veamos cómo abordar una solución: Después de comprender qué son los paréntesis equilibrados, puede pensar en usar la estructura de datos correcta y luego comenzar a escribir algoritmos (pasos) antes de comenzar a codificar la solución. Muchas veces, los propios algoritmos resuelven muchos escenarios extremos y dan mucha claridad sobre cómo se verá la solución.
Veamos la solución:
Los paréntesis balanceados son para verificar una cadena dada que contiene paréntesis (o corchetes), deben tener el mismo conteo de aperturas y cierres, así como posicionalmente bien estructurados. Para el contexto de este problema, usaremos paréntesis balanceados como - '()', '()', '{}' - es decir, una cadena dada puede tener cualquier combinación de estos corchetes.
Tenga en cuenta que antes de intentar resolver el problema, es bueno aclarar si la cadena solo contendrá los caracteres entre corchetes o cualquier número, etc. (ya que esto podría cambiar un poco la lógica)
Ejemplo: Una cadena dada - '{() {} ()} - es una cadena balanceada ya que está estructurada y tiene el mismo número de paréntesis de cierre y apertura, pero cadena -' {(}) {} () '- esta cadena - aunque tiene el mismo número de paréntesis de apertura y cierre, esto todavía no está equilibrado porque puede ver que sin un cierre '(' hemos cerrado '}' (es decir, todos los corchetes internos deben cerrarse antes de cerrar un corchete externo)
Usaremos una estructura de datos de pila para resolver este problema. Si desea obtener más información sobre los conceptos básicos de la pila, consulte Aquí
Una pila es un LIFO (tipo de estructura de datos de último en entrar, primero en salir), considérelo como una pila / pila de platos en una boda: recogerá el plato superior siempre que lo utilice.
Algoritmo:
#1) Declare una pila de caracteres (que mantendría los caracteres en la cadena y, dependiendo de la lógica, empujaría y sacaría los caracteres).
# 2) Atraviesa la cadena de entrada y siempre que
- Hay un carácter de corchete de apertura, es decir, '(‘, {‘o‘ (‘- empuja el carácter en la pila.
- Hay un carácter de cierre, es decir, ')', '}', ')' - saca un elemento de Stack y verifica si coincide con el carácter opuesto al de cierre, es decir, si el carácter es '}', entonces en Stack pop deberías esperar ' {'
- Si el elemento emergente no coincide con el paréntesis de cierre, entonces la cadena no está equilibrada y puede devolver resultados.
- De lo contrario, continúe con el enfoque de empujar y hacer estallar la pila (vaya al paso 2).
- Si la cadena se atraviesa completamente y el tamaño de la pila también es cero, entonces podemos decir / inferir que la cadena dada es una cadena de paréntesis balanceada.
En este punto, es posible que también desee analizar el enfoque de solución que tiene como algoritmo y asegurarse de que el entrevistador esté de acuerdo con el enfoque.
Código:
|_+_|La salida del fragmento de código anterior:
Al igual que hicimos con nuestros problemas de codificación anteriores, siempre es bueno ejecutar el código con al menos 1-2 entradas válidas y 1-2 entradas no válidas y asegurarse de que todos los casos se manejen adecuadamente.
NOTA: Siempre es bueno pensar en la solución en voz alta (y no solo en la mente) y, sorprendentemente, este es un rasgo importante que buscan los entrevistadores. Muchos entrevistadores podrían simplemente eliminar el algoritmo y pasar al siguiente planteamiento del problema.
En la solución de codificación anterior, para la entrevista con el desarrollador, el entrevistador puede pedir que se resuelva usando matrices en lugar de apilar directamente (es decir, usar una matriz como una pila), pero en general, se trata más de ser conceptualmente claro y capaz de manejar todo lo válido y entradas inválidas.
Relacionado con el marco de automatización de pruebas
Esta sección de la entrevista es más específica sobre las pruebas y las responsabilidades de SDET. Espere preguntas relacionadas con el diseño y el desarrollo del marco de automatización, los pros y los contras de usar diferentes enfoques, etc.
Veamos algunos ejemplos de preguntas y soluciones para las mismas.
P # 5) ¿Explica y diseña los componentes del marco de automatización para una aplicación web?
Responder: Esta pregunta es un poco subjetiva y el entrevistador tiene la intención de evaluar cuánto sabe el candidato sobre el diseño y desarrollo del marco. La respuesta a esta pregunta ayuda al entrevistador a comprender si el candidato puede construir o crear marcos personalizados desde cero.
Veamos un par de puntos que le ayudarían a estructurar la solución para esta pregunta:
- Puede hablar sobre diferentes tipos de marcos como: Marco híbrido basado en datos, basado en palabras clave.
- Modelo de objetos de página para almacenar detalles de varios elementos en diferentes páginas / módulos de la aplicación web.
- Módulos comunes como funciones auxiliares, utilidades, registradores, etc.
- Módulos de informes como generar informes de ejecución de pruebas, integrar informes con correo electrónico y programar la ejecución de pruebas, etc.
Lectura recomendada => Frameworks de automatización de pruebas más populares
P # 6) ¿Explica las estrategias de prueba para una aplicación móvil?
Responder: Por lo general, estas preguntas se hacen según el rol. Si la función es principalmente trabajar en aplicaciones móviles, entonces la pregunta tiene más relevancia. Puede hablar de su experiencia si ha planificado realizar pruebas móviles como parte de sus funciones actuales o anteriores.
Algunas sugerencias para estructurar la respuesta a esta pregunta podrían ser:
- Pruebas en dispositivos frente a emuladores.
- Identificar y almacenar objetos / elementos en diferentes pantallas - Ejemplo: Modelo de objeto de página.
- Prueba de carga de una aplicación móvil.
- Puede hablar sobre diferentes tipos de aplicaciones móviles como: aplicaciones nativas, aplicaciones híbridas y discutir estrategias / enfoques que usaría para probarlas.
Lectura recomendada => Tutoriales de prueba de aplicaciones móviles
P # 7) ¿Diseña un marco de automatización para probar las API REST?
Responder: Esta es nuevamente una pregunta subjetiva y puede hacer preguntas aclaratorias si el entrevistador quiere que desarrolle un marco para probar el comportamiento funcional de la API o requisitos no funcionales como las pruebas de carga / rendimiento.
Puede comenzar su respuesta cubriendo los siguientes puntos:
- Componentes del marco de automatización de API como configuración local, configuración simulada de API o pruebas de API alojadas.
- Herramientas utilizadas para la automatización de API. Hay varias herramientas disponibles listas para usar para validar los aspectos funcionales de una API basada en REST. Algunas de estas herramientas son Postman, Rest Assured, etc. Para obtener detalles en profundidad de las diferentes herramientas, puede consultar nuestro artículo Aquí .
- Automatización no funcional de las API.
- Ejecución programada de pruebas de automatización.
- Integración de pruebas de automatización para API.
P # 8) Preguntas específicas del marco.
Responder: A veces, dependiendo del perfil que se esté entrevistando, puede que exista un requisito para que un candidato sea competente en un determinado marco, p. Ej. Selenio, JMeter, etc.
Lectura recomendada => Cartero , Mockito , Specflow , Selenio , JMeter
Pruebas relacionadas
Aunque rara vez, pero dependiendo del perfil, puede haber preguntas sobre prácticas generales de prueba, términos y tecnologías, como la gravedad de los errores, la prioridad, la planificación de la prueba, el caso de la prueba, etc. Se espera que un SDET conozca todos los conceptos de prueba manual y debería estar familiarizado con las terminologías importantes.
En esta sección, puede esperar preguntas como estas:
P # 9) ¿Cuáles son los diferentes componentes de un plan de prueba?
Responder: Por lo general, se les pide que validen los conceptos básicos de prueba y la mentalidad. Estos términos y documentos son algo que todo control de calidad manual y SDET de automatización deben conocer.
Puede discutir varios componentes del plan de prueba aquí como,
- Criterios de entrada y salida
- Alcance: Discuta las características de prueba que están dentro del alcance y qué se automatizaría todo: serán solo características funcionales o requisitos no funcionales como escalabilidad, rendimiento, etc.
- Cronologías
- Herramientas a utilizar
- Asignación de recursos, etc.
Lectura recomendada => Cómo escribir un buen plan de prueba
P # 10) ¿Qué define y decide la prioridad y gravedad de un error?
Responder: La prioridad y la gravedad de los defectos se pueden explicar fácilmente con la ayuda de ejemplos. Supongamos que una función como el registro no funciona y evita que los usuarios accedan a la aplicación; entonces es un problema de alta prioridad y gravedad. De manera similar, puede haber ejemplos de defectos de baja gravedad / alta prioridad y varias otras combinaciones.
En general,
- Prioridad significa la importancia del problema.
- Gravedad significa el impacto que el problema está teniendo para el cliente o usuario de la aplicación.
Lectura recomendada => Prioridad y gravedad de los defectos
P # 11) ¿Qué es el particionamiento de equivalencia? Ilustre con un ejemplo.
Responder: El particionamiento de equivalencia es una técnica que se utiliza principalmente para las pruebas de caja negra, para probar varias combinaciones de entradas en un campo determinado.
Por ejemplo, Si está probando una aplicación comercial y desea escribir todos los escenarios de prueba para el campo 'Cantidad', ¿cuáles serían las diferentes entradas que probaría para este campo?
Dado que el requisito funcional es que la cantidad debe ser un valor entero positivo entre 1 y 100000. Por lo tanto, para probar varias entradas (válidas y no válidas), puede tener pruebas para 1 entrada de cada categoría.
- Valores válidos: Entre 1 y 100000 -> prueba cualquier valor válido x tal que x> 1 y x<100000.
- Valores límite: Pruebe los valores límite permitidos, es decir, 1 y 100000.
- Valores inválidos: Valores que se encuentran fuera del rango permitido, es decir, pruebe uno de esos valores para x, tal que x 100000.
Lectura recomendada => Estrategia de partición de equivalencia
Relacionado con el diseño del sistema
Las preguntas sobre el diseño del sistema suelen ser más adecuadas para las entrevistas de los desarrolladores en las que se juzga a un desarrollador sobre la base de una amplia comprensión de diferentes conceptos generales, como escalabilidad, disponibilidad, tolerancia a fallas, selección de base de datos, subprocesos, etc. En pocas palabras, necesitará utilizar todo su experiencia y conocimiento de sistemas para responder a tales preguntas.
Pero es posible que sienta que un sistema que requiere años de experiencia y cientos de desarrolladores para codificar, ¿cómo podría una persona responder la pregunta en unos 45 minutos?
La respuesta es: Aquí la expectativa es juzgar la comprensión del candidato y el amplio espectro de conocimientos que puede aplicar mientras resuelve problemas complejos.
Hoy en día, estas preguntas también comienzan a aparecer en las entrevistas SDET. Aquí la expectativa sigue siendo la misma que la de la entrevista de desarrollador, pero con criterios de juicio relajados y es principalmente una ronda para subir el listón donde, según la respuesta del candidato, un candidato puede ser considerado para el siguiente nivel o trasladado a un nivel inferior.
En general, para las preguntas de la entrevista de diseño del sistema, el candidato debe estar familiarizado con los conceptos siguientes
- Conceptos básicos de los sistemas operativos: Paginación, sistemas de archivos, memoria virtual y memoria física, etc.
- Conceptos de redes: Comunicación HTTP, pila TCP / IP, topologías de red.
- Conceptos de escalabilidad: Escala horizontal y vertical.
- Conceptos de concurrencia / subprocesos
- Tipos de bases de datos: SQL / Sin bases de datos SQL, cuándo usar qué tipo de base de datos, ventajas y desventajas de los diferentes tipos de bases de datos.
- Técnicas de hash
- Comprensión básica de CAP teorema, fragmentación, partición, etc.
Veamos algunos ejemplos de preguntas
P # 12) Diseñe un sistema de acortamiento de URL como un pequeña URL ?
Responder: Es posible que muchos candidatos ni siquiera conozcan los sistemas de acortamiento de URL en general. En ese caso, está bien preguntarle al entrevistador sobre el enunciado del problema en lugar de sumergirse sin comprender.
Antes incluso de responder a estas preguntas, los candidatos deben estructurar la solución y escribir viñetas y luego comenzar a discutir la solución con el entrevistador.
Analicemos brevemente la solución
a) Clarificar los requisitos funcionales y no funcionales
Requerimientos funcionales: El requisito funcional es simplemente desde la perspectiva del cliente, es un sistema que se alimenta con una URL grande (larga) y la salida debe ser una URL abreviada.
Cuando se accede a la URL abreviada, debe redirigir al usuario a la URL original. Por ejemplo - intente acortar una URL real en la página web https://tinyurl.com/, ingrese una URL de entrada como www.softwaretestinghelp.com y debería obtener una URL pequeña como https://tinyurl.com/shclcqa
Requerimientos no funcionales: El sistema debe ser eficaz en términos de redireccionamiento con latencia de milisegundos (ya que es un salto adicional para un usuario que accede a la URL original).
- Las URL abreviadas deben tener un tiempo de caducidad configurable.
- Las URL abreviadas no deben ser predecibles.
b) Estimación de capacidad / tráfico
Esto es muy importante desde la perspectiva de todas las preguntas sobre el diseño del sistema. La estimación de capacidad es esencialmente determinar la carga esperada que recibirá el sistema. Siempre es bueno comenzar con una suposición y discutir con el entrevistador. Esto también es importante desde la perspectiva de la planificación del tamaño de la base de datos, ya sea que el sistema sea de lectura o escritura, etc.
Hagamos algunos números de capacidad para el ejemplo del acortador de URL.
Supongamos que habrá 100.000 nuevas solicitudes de acortamiento de URL por día (con una proporción de lectura-escritura de 100: 1, es decir, por cada 1 URL acortada, tendremos 100 solicitudes de lectura contra la URL acortada)
Entonces tendremos,
|_+_|c) Consideraciones de almacenamiento y memoria
Después de los números de capacidad, podemos extrapolar estos números para obtener,
- La capacidad de almacenamiento que se requeriría para acomodar la carga esperada, Por ejemplo, podemos planificar el diseño de una solución de almacenamiento para respaldar las solicitudes hasta por 1 año.
Ejemplo: Si cada URL abreviada consume 50 bytes, el total de datos / almacenamiento que necesitaríamos durante un año sería:
- Las consideraciones sobre la memoria son importantes para planificar el sistema desde la perspectiva del lector. es decir, para sistemas que requieren mucha lectura, como el que estamos intentando construir (porque la URL se crearía una vez pero se accedería a ella varias veces).
Los sistemas pesados de lectura generalmente usan el almacenamiento en caché para mejorar su rendimiento y evitar leer desde el almacenamiento permanente para ahorrar en E / S de lectura.
Supongamos que queremos almacenar el 60% de nuestras solicitudes de lectura en la caché, por lo que durante el año necesitaríamos el 60% del total de lecturas durante el año x bytes requeridos por cada entrada.
|_+_|Entonces, según nuestros números de capacidad, este sistema requeriría aproximadamente 1 GB de memoria física
d) Estimaciones de ancho de banda
Se requieren estimaciones de ancho de banda para analizar la velocidad de lectura y escritura en bytes que se requeriría para que se ejecute un sistema. Hagamos estimaciones contra las cifras de capacidad que hemos tomado.
Ejemplo: Si cada URL abreviada consume 50 bytes, las velocidades totales de lectura y escritura que necesitaríamos serían las siguientes:
|_+_| e) Diseño y algoritmo del sistema
Esta es esencialmente la lógica o el algoritmo empresarial principal que se utilizaría para cumplir con los requisitos funcionales. En este caso, queremos generar URL abreviadas únicas para una URL determinada.
Los diferentes enfoques que podrían utilizarse para generar URL abreviadas son:
Hashing: Podemos pensar en generar URL acortadas creando un hash de la URL de entrada y asignando la clave hash como URL acortada.
Este enfoque puede tener algunos problemas cuando hay diferentes usuarios del servicio, y si ingresan la misma URL, obtendrían la misma URL abreviada.
Cadenas acortadas creadas previamentey asignados a las URL cuando se llama al servicio: Otro enfoque puede ser devolver una cadena acortada predefinida del grupo de cadenas ya generadas.
API de servicio: Podemos pensar en el sistema de acortador de URL como un conjunto de API basadas en REST que tienen los siguientes puntos finales:
- createUrl (String Url, DateTime expiryTime): Este punto final crea y devuelve una URL abreviada con una duración de vencimiento establecida como se especifica en la entrada.
- retrieveUrl (String shortenedUrl): Este punto final recupera la URL para redirigirla a la URL abreviada dada.
f) Escalado y concurrencia
La escala es una consideración importante desde una perspectiva de requisitos no funcionales.
Se trata de ¿cómo puede el sistema
- Escala bajo carga: El sistema debe poder escalar con gracia bajo carga y no simplemente dejar de funcionar después de que ocurra un pico inesperado en la carga.
Lectura recomendada => Técnicas de escala
- ¿Qué rendimiento puede tener el sistema? por ejemplo: Si el sistema se utiliza con capacidad sostenida durante mucho tiempo, ¿se degradaría el rendimiento del sistema o se mantendría estable?
Puede haber muchas preguntas de diseño de sistemas diferentes, como las que se muestran a continuación, pero en general, todas ellas pondrían a prueba la comprensión más amplia del candidato de los diferentes conceptos que hemos discutido en la solución del sistema de acortamiento de URL.
P # 13) Diseñe una plataforma de videos como Youtube.
Responder: Esta pregunta también se puede abordar, de manera similar a como hemos discutido la pregunta TinyUrl anterior (y esto se aplica a casi todas las preguntas de la entrevista de diseño del sistema). El único factor diferenciador sería mirar / detallar alrededor del sistema que desea diseñar.
Entonces, para Youtube, todos sabemos que es una aplicación de transmisión de video y tiene muchas capacidades como permitir que un usuario cargue nuevos videos, transmita webcasts en vivo, etc. Entonces, mientras diseña el sistema, debe aplicar los componentes de diseño del sistema requeridos. En este caso, es posible que necesitemos agregar componentes relacionados con las capacidades de transmisión de video.
Puede discutir puntos como,
- Almacenamiento: ¿Qué tipo de base de datos elegiría para almacenar contenido de video, perfiles de usuario, listas de reproducción, etc.?
- Seguridad y autenticación / autorización
- Almacenamiento en caché: Dado que una plataforma de transmisión como youtube debería tener un buen rendimiento, el almacenamiento en caché es un factor importante para diseñar cualquier sistema de este tipo.
- Simultaneidad: ¿Cuántos usuarios pueden transmitir video en paralelo?
- Otras funcionalidades de la plataforma, como el servicio de recomendación de videos, que recomienda / sugiere a los usuarios los próximos videos que pueden ver, etc.
P # 14) Diseñe un sistema eficiente para operar 6 ascensores y asegúrese de que una persona tenga que esperar un tiempo mínimo mientras espera que llegue el ascensor. ?
Responder: Estos tipos de preguntas de diseño de sistemas son de nivel más bajo y esperarían que el candidato pensara primero en el sistema de ascensores y enumerara todas las funciones posibles que necesitan soporte y diseñe / cree clases y relaciones / esquemas DB como la solución.
Desde la perspectiva de SDET, el entrevistador solo esperaría que las clases principales que usted cree que tenga su aplicación o sistema y las funcionalidades básicas se manejen con la solución sugerida.
Veamos varias funcionalidades del sistema de ascensores que se esperarían
Puede hacer preguntas aclaratorias como
- ¿Cuántos pisos hay?
- Cuantos ascensores hay?
- ¿Todos los ascensores son de servicio / de pasajeros?
- ¿Están todos los ascensores configurados para detenerse en cada piso?
Estos son los diferentes casos de uso que son aplicables para un sistema de ascensor simple:
En términos de clases / objetos principales de este sistema, puede considerar tener:
- Usuario: Se ocupa de todas las propiedades de un usuario y las acciones que puede realizar en el objeto Elevator.
- Ascensor: Elevator Propiedades específicas como altura, ancho, número_serie_elevador.
- Puerta del ascensor: Todo lo relacionado con la puerta como sin puertas, tipo de puerta, automática o manual, etc.
- Elevator_Button_Control: Diferentes botones / controles disponibles en el ascensor y diferentes estados en los que pueden estar esos controles.
Una vez que haya terminado de diseñar clases y sus relaciones, puede hablar sobre la configuración de esquemas de base de datos.
Otro componente importante del sistema Elevator es Eventing System. Puede hablar sobre la implementación de colas o en una configuración más compleja, creando flujos de eventos utilizando Apache Kafka, donde los eventos se envían a los sistemas respectivos para actuar.
El sistema de eventos es un aspecto importante, ya que hay varios usuarios (en diferentes pisos) que utilizan el ascensor al mismo tiempo. Por lo tanto, las solicitudes del usuario deben ponerse en cola y ser atendidas según la lógica configurada en los controladores del elevador.
Q # 15) Diseño Instagram / Twitter / Facebook.
Responder: Todas estas plataformas están relacionadas de alguna manera, ya que permiten a los usuarios conectarse de una forma u otra y compartir cosas a través de diferentes tipos de medios, como mensajes / videos y chats también.
Por lo tanto, para este tipo de aplicaciones / plataformas de redes sociales, debe incluir los puntos siguientes al discutir el diseño de dichos sistemas (además de lo que hemos discutido para diseñar un sistema de acortamiento de URL):
- Estimación de capacidad: La mayoría de estos sistemas serían de lectura intensiva, por lo que se requiere una estimación de la capacidad y nos permitiría asegurar que la configuración adecuada del servidor y la base de datos esté garantizada para atender la carga requerida.
- Esquema DB: Los principales esquemas de base de datos importantes que deben discutirse son: detalles de usuario, relaciones de usuario, esquemas de mensajes, esquemas de contenido.
- Servidores de alojamiento de imágenes y videos: La mayoría de estas aplicaciones tienen videos e imágenes compartidas entre usuarios. Por lo tanto, los servidores de alojamiento de imágenes y videos deben configurarse según las necesidades.
- Seguridad: Todas estas aplicaciones deben garantizar un alto nivel de seguridad debido a la información del usuario / información de identificación personal de los usuarios que almacenan. Cualquier intento de piratería, SQL Injection no debería tener éxito en estas plataformas, ya que podría costar la pérdida de datos de millones de clientes.
Problemas basados en escenarios
Los problemas basados en escenarios son generalmente para personas de alto nivel, donde se dan diferentes escenarios en tiempo real y se le pregunta al candidato qué piensa sobre cómo manejarán tal situación.
P # 16) Dado que es necesario publicar una revisión crítica lo antes posible, ¿qué tipo de estrategia de prueba tendría?
Responder: Ahora, aquí el entrevistador esencialmente quiere entender
- ¿Cómo y qué tipo de estrategias de prueba se le ocurren?
- ¿Qué cobertura haría para una revisión?
- ¿Cómo validaría la revisión posterior a la implementación? etc.
Para responder a tales preguntas, podría utilizar situaciones de la vida real si pudiera identificarse con el problema. También debe mencionar que sin las pruebas adecuadas, no estaría dispuesto a lanzar ningún código a producción.
Para las correcciones críticas, siempre debe trabajar en conjunto con el desarrollador e intentar comprender qué áreas podría afectar y preparar un entorno que no sea de producción para replicar el escenario y probar la corrección.
También es importante mencionar aquí que continuará monitoreando la solución (usando herramientas de monitoreo, paneles, registros, etc.) después de la implementación para ver cualquier comportamiento anormal en el entorno de producción y asegurarse de que no haya un impacto negativo de la solución que está hecho.
También puede haber otras preguntas que son principalmente para comprender la perspectiva del candidato sobre las pruebas de automatización, los plazos de entrega, etc. (y estas preguntas pueden variar de una empresa a otra, así como la antigüedad del puesto. Por lo general, estas preguntas se hacen para el nivel senior / lead roles)
P # 17) ¿Sacrificaría las pruebas completas para lanzar un producto rápidamente?
Responder: Estas preguntas generalmente involucran al entrevistador para que comprenda sus pensamientos desde una perspectiva de liderazgo y cuáles son las cosas en las que se comprometería, y ¿estaría dispuesto a lanzar un producto con errores en lugar de menos tiempo?
Las respuestas a estas preguntas deben fundamentarse en las experiencias reales del candidato.
Por ejemplo, Podría mencionar que en el pasado, tenía que atender una llamada para lanzar alguna revisión, pero no se pudo probar debido a la falta de disponibilidad del entorno de integración. Entonces lo lanzó de manera controlada: implementando un porcentaje más pequeño y luego monitoreando los registros / eventos y luego iniciando el lanzamiento completo, etc.
P # 18) ¿Cómo crearía una estrategia de automatización para un producto que no tiene ninguna prueba de automatización?
Responder: Este tipo de preguntas son abiertas y generalmente son un buen lugar para abordar la discusión de la manera que desee. También puede mostrar sus habilidades, conocimientos y áreas tecnológicas que son su fortaleza.
Por ejemplo, para responder a este tipo de preguntas, puede citar ejemplos de la estrategia de automatización que adoptó al crear un producto en su puesto anterior.
Por ejemplo, podrías mencionar puntos como,
- Dado que el producto requería comenzar la automatización desde cero, tuvo suficiente tiempo para pensar y diseñar un marco de automatización apropiado eligiendo un lenguaje / tecnología que la mayoría de las personas tenían el conocimiento para evitar la introducción de una nueva herramienta y aprovechar el conocimiento existente.
- Comenzó con la automatización de los escenarios funcionales más básicos que se consideraban P1 (sin los cuales no podría realizarse ninguna versión).
- También pensó en probar el rendimiento y la escalabilidad del sistema a través de herramientas de prueba automatizadas como JMETER, LoadRunner, etc.
- Pensó en automatizar los aspectos de seguridad de la aplicación que se enumeran en la OWASP Estándares de seguridad.
- Has integrado las pruebas automatizadas en el proceso de compilación para obtener comentarios tempranos, etc.
Ajuste del equipo y ajuste de la cultura
Esta ronda generalmente depende de una empresa a otra. Pero la necesidad / necesidad de esta ronda es comprender al candidato desde la perspectiva de la cultura del equipo y la organización. El propósito de estas preguntas también es comprender la personalidad del candidato y su enfoque hacia el trabajo / las personas, etc.
Generalmente, los gerentes de recursos humanos y contratación son los que llevan a cabo esta ronda.
Las preguntas que suelen surgir durante esta ronda son como:
P # 19) ¿Cómo resuelve los conflictos dentro de su función actual?
Responder: Una explicación más detallada aquí es: suponga que tiene un conflicto con su jefe o miembros inmediatos del equipo, ¿cuáles son los pasos que debe seguir para resolver esos conflictos?
Para este tipo de preguntas, sustente tanto como pueda con ejemplos reales que podrían haber sucedido dentro de su carrera en organizaciones actuales o anteriores.
Puedes mencionar cosas como:
- Le gusta solucionar lo antes posible cualquier conflicto que surja como resultado de razones profesionales (y no le gustaría afectar sus relaciones personales debido a esto).
- Puede mencionar que generalmente intenta comunicarse de manera efectiva y hablar / discutir con la persona individualmente para resolver cualquier diferencia / problema.
- Puede mencionar que si las cosas empiezan a empeorar, necesitará la ayuda de una persona de alto nivel / su gerente y obtendrá sus aportes.
A continuación se muestran otros ejemplos de preguntas de adaptación al equipo / adaptación a la cultura (la mayoría de ellas deben responderse con un enfoque similar al que discutimos para la pregunta anterior. Hablar sobre escenarios de la vida real es una clave aquí, ya que el entrevistador puede relacionarlo de una mejor manera como bien.
P # 20) ¿Qué tipo de equilibrio entre el trabajo y la vida privada espera del nuevo puesto para el que se considera que lo contrataron?
Responder: Dado que el gerente de contratación es alguien que sabe lo que exige el puesto, a veces se puede requerir mucho esfuerzo adicional, por lo que, en general, el entrevistador trata de evaluar si sus expectativas son radicalmente diferentes de lo que espera el puesto.
Supongamos que dices que no prefiere asistir a las reuniones nocturnas y el rol espera que tenga una gran colaboración entre un equipo que se sienta en una zona horaria diferente, entonces el entrevistador podría iniciar una discusión sobre estas son las expectativas del rol - ¿Podrá ¿adaptar? etc.
De nuevo, esta es una conversación más informal, pero desde la perspectiva del entrevistador, ellos quieren entender sus expectativas para evaluar su candidatura para el puesto para el que están siendo entrevistados.
P # 21) Aparte del trabajo, ¿cuáles son sus pasatiempos?
Responder: Estas preguntas son puramente subjetivas y específicas de cada individuo, y estas preguntas generalmente son útiles para hacer que el candidato se sienta relajado y tranquilo e iniciar discusiones informales.
En general, las respuestas a estas preguntas podrían ser como: te gusta leer un género en particular, te gusta la música, recibiste algún premio por alguna actividad voluntaria / filantrópica, etc. Además, estas preguntas generalmente se hacen en la ronda de recursos humanos (y es menos probable que lo pregunte un técnico).
P # 22) ¿Cuánto tiempo está dispuesto a dedicar a aprender nuevas herramientas y tecnologías de forma proactiva?
Responder: Aquí, el entrevistador está evaluando su voluntad de aprender cosas nuevas si se le presenta algo inusual o nuevo. ¿También le permite al entrevistador saber que eres proactivo? ¿Estás dispuesto a invertir en ti y en tu carrera? etc.
Por lo tanto, al responder tales preguntas, sea honesto y respalde sus respuestas con ejemplos. Por ejemplo, Podría mencionar que se presentó para una certificación de Java el año pasado y se preparó fuera del trabajo tomando algunas horas cada semana.
Conclusión
En este artículo, analizamos el proceso de entrevista del ingeniero de desarrollo de software en prueba y ejemplos de preguntas que generalmente se hacen a los candidatos de diferentes organizaciones y perfiles. En general, las entrevistas SDET son de naturaleza muy amplia y dependen en gran medida de una empresa a otra.
Pero los procesos de entrevista son similares a los que existen para un perfil de desarrollador con un mayor énfasis en los marcos de calidad y automatización.
Es importante entender que, hoy en día, las empresas están menos enfocadas en un lenguaje o tecnología específicos, pero más en una comprensión amplia de conceptos y la capacidad de adaptarse a las herramientas / tecnologías requeridas por la empresa.
¡Mis mejores deseos para su entrevista SDET!
Lectura recomendada
- ¿Qué es SDET? Conozca la diferencia entre Tester y SDET
- Preguntas y respuestas de la entrevista
- Preguntas y respuestas de la entrevista de prueba ETL
- Algunas preguntas y respuestas complicadas sobre pruebas manuales
- Preguntas de la entrevista de Spock con respuestas (las más populares)
- Las 25 mejores preguntas y respuestas de la entrevista de pruebas ágiles
- Las 32 mejores preguntas y respuestas de las entrevistas de Datastage
- Más de 20 preguntas y respuestas de entrevistas .NET