23 preguntas de entrevista para ingenieros de software senior

Si te estás preparando para conseguir un nuevo trabajo, echa un vistazo a estas preguntas más frecuentes de entrevista para el puesto de ingeniero de software senior.

Tanto los solicitantes de trabajo de ingeniero de software remoto como en sitio, pueden esperar una serie de preguntas que cubre sus capacidades técnicas, los temas con los que deben estar familiarizados y su habilidad de resolución de problemas.

Este post cubre más de 20 preguntas y respuestas de entrevista para ingeniero de software senior que te ayudarán a prepararte para superar esta etapa.

Aquí dejamos una guía completa de las mejores preguntas para entrevistas de ingeniero de software senior. Vamos a profundizar.

1. ¿Cuáles son las limitaciones de la Programación Orientada a Objetos (OOP)?

Algunas de las limitaciones de OOP son las siguientes, y puedes agregar otras que conozcas:

• Los programas elaborados con este método pueden tener un tamaño considerablemente más grande que los programas escritos con la metodología orientada a procesos (POP).
• Asimismo, este estilo de desarrollo de software requiere de una gran cantidad de preparación y previsión. Si no se dispone de la documentación de clases pertinente, el código creado para Programación Orientada a Objetos puede ser difícil de comprender.
• Además, las aplicaciones pueden consumir una gran cantidad de memoria en determinadas situaciones.

2. ¿Cuál es la diferencia entre herencia prototipo y herencia clásica en la Programación Orientada a Objetos?

Hay dos tipos de abstracciones en la Programación Orientada a Objetos tradicional: clases y objetos. Un objeto es una abstracción de una entidad del mundo real. En cambio, una clase es una abstracción de un objeto o de otra clase (puedes imaginarla como una generalización).

Como resultado, a medida que aumenta el grado de abstracción, las entidades se vuelven más generalizadas, y cuando disminuye, las entidades se vuelven más particulares. El grado de abstracción se compara con una escala que abarca desde las entidades más particulares a las más generalizadas.

Dado que la programación orientada a objetos prototipo sólo tiene una forma de abstracción, los lenguajes de Programación Orientada a Objetos prototipo son mucho más sencillos que los lenguajes de Programación Orientada a Objetos clásicos (objetos).

Objetos en la Programación Orientada a Objetos prototipo Los lenguajes de programación son abstracciones de objetos del mundo real (denominados también objetos) o de otros objetos (conocidos como prototipos de los objetos de los que son abstaccción). Consecuentemente, un prototipo es una generalización.

En los lenguajes de programación orientados a objetos prototipo, los objetos pueden crearse desde cero (ex-nihilo) o a partir de otros objetos (que entonces se convierten en prototipos del objeto recién creado).

3. ¿Cuál es la diferencia entre entrega continua (CDy) y despliegue continuo (CDt)?

No se puede hablar de entrega continua y despliegue continuo sin hablar de integración continua (IC).

• La Integración Continua se usa para automatizar las compilaciones (builds). Es la práctica de fusionar, rápida y frecuentemente, las modificaciones de código en el canal o pipeline principal. IC es la base de un proceso de compilación predecible, fiable y siempre accesible. Con la IC, las revisiones se confirman generando una compilación y ejecutando pruebas automatizadas con ella para evitar errores y problemas que pueden surgir si todos los cambios se fusionan en la rama de publicación el día de la publicación.
• La Entrega Continua aumenta la integración continua al liberar automáticamente cualquier cambio en el código que se produzca tras el paso de compilación, ya sea al entorno de pruebas o de producción. Esto implica que dispones de un procedimiento (además de las pruebas automatizadas) de lanzamiento automático y puedes desplegar tu aplicación en cualquier momento con sólo pulsar un botón.
• El Despliegue Continuova un paso más allá de la Entrega Continua. Cada actualización que supere todas las fases del proceso de desarrollo es distribuida a tus usuarios mediante este método. No hay interacción humana; sólo un fallo en la etapa de pruebas impedirìa que una nueva modificación entre en producción. El despliegue continuo es una técnica fantástica para acortar el sistema de retroalimentación con tus clientes y aliviar la tensión del equipo, al no haber un día de lanzamiento prefijado.

4. ¿Qué herramientas de gestión de la configuración de software has utilizado?

Las preguntas de entrevista para desarrolladores de software senior a menudo solicitan respuestas acerca de cuáles son las principales herramientas de gestión de la configuración, entre ellas:

• Ansible
• CHEF
• JUJU
• ConfigHub
• CFEngine
• SALTSTACK
• RUDDER
• Monitor de configuración del servidor SolarWinds
• Despliegue Octopus Deploy

La lista continúa. Sin embargo, siempre es recomendable que menciones herramientas que conoces bien, por si hay preguntas de seguimiento.

5. ¿En qué casos es mejor una arquitectura de microservicios que una monolítica?

Una aplicación monolítica está construida como una entidad cohesionada, mientras que una arquitectura de microservicios se compone de servicios más pequeños, con desplieges individuales.

Los microservicios no son una solución universal, pero alivian muchos problemas del desarrollo de software y empresas.

Dado que una arquitectura de microservicios se compone de piezas que se ejecutan por separado, cada servicio puede construirse, actualizarse, distribuirse y escalarse independientemente de los demás. Las actualizaciones de software pueden llevarse a cabo con mayor frecuencia, lo que se traduce en una mayor fiabilidad, disponibilidad y rendimiento.

Por lo tanto, son perfectas para aplicaciones de big data, modernización y eliminación progresiva de aplicaciones legacy, procesamiento de datos en tiempo real, adopción del modelo DevOps, desarrollos multigrupales y otros proyectos que requieren las ventajas únicas que los microservicios ponen a su disposición.

6. ¿Qué tipos de código que apesta conoces?

Un code smell o código que apesta, en programación informática, es cualquier rasgo en el código fuente de un programa que puede indicar un problema mayor y, por tanto, puede requerir refactorización. Algunas de las más comunes son:

• Bloaters: Método Largo, Primitive Obsession, Lista Larga de Parámetros, Oddball Situations, Datos Amontonados-Data Clumps, Class Doesn’t Do Much/Clase Inerte, Código Requerido de Configuración/Desmontaje (Required Setup/Teardown Code), etc.
• Ofuscador: Nombres Deficientes, Separación Vertical, Comentarios, Regiones, Inconsistencia, Obscured Intent, etc.
• Bloqueadores de cambios: Shotgun Surgery, pruebas mal escritas, Jerarquías de Herencia Paralela, Cambio divergente, Niveles de Abstracción Incoherentes, Complejidad Condicional, etc.
• Acopladores: Tramp Data, acoplamiento artificial, intermediario, Feature Envy, Indecent Exposure, dependencias ocultas, violaciones de la ley de Demeter, Inappropriate Intimacy, Hidden Temporal Coupling, etc.
• Dispensables: Dead Code, Lazy Class, código duplicado, generalidad especulativa, clase de datos, etc.
• Prueba de apeste/smells: Nitpicker, Catcher codicioso, Secuenciador, Fragilidad, Falta de pruebas, Seco contra húmedo, Loudmouth, El Enumerador, Mockery, El Gigante, Dependencia oculta, Vacío, Pruebas ocultas, Esperar y ver, El Uno, Echar los dados, etc.

7. ¿Cómo prevenir la deuda técnica?

El coste previsto de rediseñar el software se denomina deuda técnica. Es el resultado de utilizar soluciones simples y limitadas durante el desarrollo del software, con el fin de ahorrar tiempo de producción. Para evitarlo, pueden tomarse algunas medidas:

• Crea la documentación adecuada antes de iniciar cualquier proyecto, así garantizas que se tienen en cuenta las correcciones, las pruebas y la implementación. Actualiza esta documentación con regularidad.
• Utilizar enfoques de desarrollo ágiles para lograr velocidad sin tomar atajos y, al mismo tiempo, tener la valiosa capacidad de realizar modificaciones pertinentes, a medida que avanza el proyecto.
• Elige o reúne un equipo de desarrolladores en los que puedas confiar para que siempre entreguen lo que se necesita. Los desarrolladores competentes agilizan la colaboración con un mínimo de fricciones y errores.
• Es importante no caer en la tentación de ahorrar dinero y tiempo. No vale la pena. La calidad siempre debe primar, si no quieres volver atrás y acabar haciendo cambios a posteriori.
• Las pruebas son importantes y deben establecerse en cada fase, con una lista de control de los hitos y modificaciones que deben realizarse antes de pasar a la siguiente. etapa.
• Un plan anual de mantenimiento del sistema es crucial para que un ingeniero de software senior tenga éxito.

Hay algunas otras medidas que aplicar, con la meta subyacente de prevenir errores y decisiones costosas.

8. ¿Con qué estrategias de despliegue has trabajado?

Las estrategias de despliegue son prácticas usadas para actualizar o cambiar una instancia en ejecución de una aplicación. Algunos de los tipos más comunes de despliegue son:

• Básico
• Multiservicio
• Rolling/Ramped
• Azul-verde (Blue-Green)
• Canario
• Pruebas A/B
• Recrear (Highlander)
• Sombra-Shadow

Las estrategias se adaptan a distintas situaciones, y a menudo se eligen en función de cómo repercuten en el sistema y los usuarios finales.

9. ¿Qué es una pirámide de pruebas?

La pirámide de pruebas es un modelo que clasifica las pruebas de software en tres formas. Esto ayuda a los expertos en control de calidad y desarrolladores a garantizar una mayor calidad, reducir el tiempo necesario para descubrir la causa subyacente de los errores y desarrollar un sistema de pruebas más fiable.

La pirámide de pruebas tiene tres niveles. La base de la pirámide se utiliza para las pruebas unitarias, la etapa intermedia para las pruebas de integración y la capa superior y final para las pruebas exploratorias y de interfaz de usuario.

10. Explica el proceso de las pruebas de extremo a extremo

Las pruebas de extremo a extremo son un enfoque de pruebas de software que evalúan el software por completo, de principio a fin, incluida su integración con otras interfaces.

Las pruebas de extremo a extremo tienen en cuenta todo el software en cuanto a dependencias, integridad de los datos y conectividad con otros sistemas, bases de datos e interfaces para simular un entorno de producción completo.

Este testeo comprueba el procesamiento de lotes y datos de varios sistemas ascendentes y descendentes y el sistema de software, que es la razón por la que el enfoque recibe el nombre de "extremo a extremo". Las pruebas de extremo a extremo suelen realizarse después de las pruebas funcionales y de sistema.

El testeo simula las condiciones en tiempo real, utilizando datos de producción auténticos y un ambiente de prueba. Las pruebas de extremo a extremo también se conocen como pruebas en cadena o concatenadas.

11. ¿Cuáles son las ventajas del TDD sobre el BDD?

El Desarrollo Orientado a Pruebas (TDD) y el Desarrollo Orientado al Comportamiento (BDD) tienen sus propios méritos y deméritos. Cuando se comparan los dos, TDD supera a BDD cuando se trata de:

• Proyectos que incluyen API y herramientas de terceros
• Proyectos que están orientados a reducir la probabilidad de encontrar errores durante las pruebas
• Proyectos en los que las pruebas solo deben satisfacer únicamente al desarrollador y su código, en contraste con BDD, en el que las pruebas deben satisfacer tanto al desarrollador como al cliente.

Los equipos ágiles han adoptado ampliamente el desarrollo basado en pruebas, y existen muchas herramientas diferentes para ayudar a los equipos a ponerse de acuerdo. Por desgracia, hay menos herramientas para el desarrollo basado en comportamiento, ya que implica mantener comunicación entre los equipos técnicos y empresariales.

12. ¿Qué normas de seguridad conoces?

La seguridad de las aplicaciones (AppSec) es fundamental actualmente para garantizar la continuidad de la empresa. Aunque la seguridad nunca es sinónimo de cumplimiento, debes conocer las siguientes normas de seguridad de las aplicaciones para ofrecer bases mínimas de implementación de mejores prácticas:

• Organización Internacional de Estandarización (ISO) 27034
• Centro para la Seguridad del Internet (CIS) Control 16: Seguridad para software de aplicaciones
• Estándar de seguridad de datos de aplicaciones de pago (PA-DSS) del sector de tarjetas de pago (PCI)
• Norma OWASP de verificación de seguridad de las aplicaciones (ASVS)
• Publicación especial (SP) 800-218 (BORRADOR) del Instituto Nacional de Tecnologías (NIST)
• CWE (Enumeración de debilidades comunes)
• MISRA-C (Asociación de confiabilidad del software en la industria motorizada) para el lenguaje de programación C.
• HIPAA (Ley de Portabilidad y Responsabilidad del Seguro de Salud)
• Consorcio de Seguridad de las Aplicaciones Web (WASC)

13. ¿Cómo evitar la exposición de datos sensibles?

Los datos sensibles son información altamente confidencial que debe mantenerse segura y no estar al alcance de personas no autorizadas. Los datos confidenciales incluyen información como direcciones, salarios, datos de clientes, datos de tarjetas de crédito o débito, e información que debe protegerse en caso de filtración de datos:

• Eliminar todos los datos sensibles una vez que hayan cumplido su función
• Cifrar todos los datos confidenciales que posea
• Utilizar herramientas de pruebas seguras para detectar problemas en una fase temprana
• Predecir las amenazas que puedas enfrentar, y prepararte o defenderte contra ellas
• Desabilitar el almacenamiento en caché y el autocompletado de formularios que contengan o recojan información confidencial de datos
• Utilizando servicios de nube como KeyVault en Azure o KMS en AWS
• Utilizar contraseñas y claves seguras
• Clasificar los datos

14. Nombra los 10 principales fallos de seguridad de OWASP

El Top 10 de OWASP es un punto de partida sólido a la hora de crear código seguro. Un porcentaje significativo de aplicaciones tienen al menos un problema de seguridad dentro del Top 10 de OWASP. Entre ellos se incluyen:

1. Inyección
2. Exposición de datos sensibles
3. Autenticación defectuosa
4. Control de acceso defectuoso
5. Inyección XXE
6. Desconfiguración de seguridad
7. Deserialización insegura
8. Secuencias de comandos cruzados (Cross-site scripting)
9. Registro y supervisión insuficientes
10. Uso de componentes con vulnerabilidades conocidas

15. ¿Cuándo es mejor aplicar SAFe? (Marco Ágil Escalado)

SAFe (Scaled Agile Framework) suele aplicarse mejor cuando:

• No hay otros esfuerzos en curso de transformación de agilidad.
• Prefieres los cambios reales a los cosméticos.
• Un ciclo de publicación de 10-12 semanas es adecuado.
• Los artículos de ferretería u otros productos con plazos de entrega largos (hasta 10 semanas) requieren integrarse con artículos con plazos de entrega más cortos.
• No se desea reducir el tamaño de la organización.
• No se desea crear una organización Lean/Agile con puestos exclusivamente Lean/Agile a varios niveles, como Propietario de Arquitectura, Gestor de Flujo y Propietario de Producto.
• El sistema Kanban se utiliza a todos los niveles, ya que se aplica a nivel de equipo.
• Cuando quieres mejorar el rendimiento del equipo, sentirte cómodo y estar preparado para volverse ágil.
• Cuando DevOps está completamente aceptado, y la automatización de pruebas es un elemento integral del funcionamiento de la empresa.
• Todas las personas afectadas por SAFe, reciben una formación formal en SAFe.Cuando SAFe está documentado, pero se requiere un cambio de mentalidad, que puede lograrse mediante la instrucción en clase.
• Los Product Owners tienen plenos poderes y ningún puesto socava su función.

16. Nombra y explica los roles del Scrum

Existen tres roles principales en Scrum. Estos incluyen:

• El Scrum Master, que garantiza que un equipo Scrum funcione de la manera más eficiente posible, siguiendo los ideales de Scrum, manteniendo al equipo en curso, preparando y dirigiendo las reuniones y resolviendo cualquier obstáculo que pueda surgir.
• Dueño de Producto/Scrum Product Owner, se asegura que el equipo Scrum esté en la misma página que los objetivos generales del producto. Sus responsabilidades abarcan los requisitos comerciales del producto, tales como las expectativas del consumidor y tendencias de la industria.
• Equipo de desarrollo, que incluye a los expertos que realizan el trabajo en el sprint de Scrum sobre el terreno. Esto implica que los miembros del equipo de desarrollo son capaces de usar cualquier habilidad necesaria para cumplir los objetivos del sprint.

17. ¿Alguna vez has tenido que introducir un nuevo proceso en el trabajo? ¿Qué enfoque adoptaste para conseguir la cooperación de tu equipo?

Sea lo que sea lo que hayas introducido, los métodos para conseguir la cooperación tienden a ser los mismos:

• Comunica claramente la necesidad del cambio.
• Cuenta con el respaldo de la dirección y las figuras clave de la organización.
• Adapta el material introductorio a las necesidades de los empleados.
• Utiliza ayudas visuales para acelerar la adopción de tus nuevos procesos.
• Comparte toda la documentación pertinente o necesaria.
• Asegúrate que los empleados no se sienten presionados para tener éxito ni temen el fracaso.

18. Describe una situación en la que hayas logrado convencer a otros de tus ideas

Siempre que haya que convencer a los demás de una idea en un lugar de trabajo, hay que considerar algunos pasos:

• Haz favores a los demás, sobre todo cuando no te pidan mucho, y tendrás oyentes dispuestos a escucharte cuando les propongas ideas.
• Establece cuáles son tus objetivos, para que los demás tengan algo en lo que centrarse.
• Inicia una conversación con las personas más afectadas por los cambios que la idea pueda acarrear.
• Utiliza fuentes fiables para apuntalar tu idea.
• Prepar de antemano lo que quiere decir o poner en práctica para captar la atención de tu público y mantenerla durante tu presentación.
• Muestra a tu público cómo será el resultadopara que tengan un incentivo para querer lo que estás sugiriendo.

Hay más formas de convencer a la gente de tus ideas, y todas ellas deben equilibrarse adecuadamente para impulsar el cambio.

19. ¿Has participado alguna vez en la comunicación directa con un cliente?

El prototipo del desarrollador se centraría en las líneas de código y las tareas asociadas y suele despreocuparse de las exigencias del cliente. Pero no siempre es así en la vida real.

El negocio de la ingeniería de software está en continua expansión, y cada vez hemos ido encontrando más programadores a los que no les complica entablar comunicación con el cliente.

Resulta que esta estrategia ayuda a crear mejores productos. Además, la inventiva de los programadores, su pensamiento innovador y experiencia, pueden evitar varios problemas durante el desarrollo.

20. ¿Has realizado estudios de usuarios? De ser así, ¿de qué tipo?

La investigación de usuario se clasifica en dos tipos

• La Investigación Cuantitativa suele ser exploratoria y se usa para definir un problema mediante la creación de datos estadísticos o datos, que puedan convertirse en estadísticas significativas. Los enfoques frecuentes de recopilación de datos son: sondeos en línea, cuestionarios en papel, encuestas móviles, estudios longitudinales, los inspectores in situ, encuestas de opinión y observaciones sistemáticas.
• La investigación cualitativa de usuarios es un examen de observación del comportamiento. Se trata de conocer las ideas y prácticas de las personas en sus propios términos. Algunas de las metodologías que pueden usarse son la observación contextual, investigación etnográfica, entrevistas, investigación de campo y pruebas de usabilidad controladas.

21. ¿Has tenido que tomar alguna vez una decisión de gran impacto? ¿Cómo la has afrontado?

Para tomar decisiones de gran impacto, hay que incluir a todos quienes se verán afectados por los cambios que se realicen. Por eso, cuando estés a punto de tomar una decisión de gran impacto, debes asegurarte de que:

• Identifica y define el contexto y las limitaciones.
• Presenta al menos dos soluciones, para evitar ser víctima de la ley del sesgo de instrumento
• Registra todas las decisiones tomadas y todos los datos relevantes a su alrededor para asegurarte de que siempre puedes identificar por qué hiciste un cambio y cómo lo hiciste.
• Celebra reuniones o charlas con todos los implicados para recabar su opinión sobre lo que te gustaría implementar.

Después de todo esto, puedes documentar los cambios, aplicarlos y comunicar la información pertinente a las partes implicadas.

22. ¿Qué entiendes por éxito de un proyecto?

Se considera que un proyecto tiene éxito si se termina en el plazo previsto, se ajusta al presupuesto, cumple los objetivos, el alcance y los requisitos de rendimiento, y es aceptado por los usuarios.

23. ¿Eres colaborador de código abierto?

Tanto dentro como fuera del sector, hay quienes coinciden que contribuir a proyectos de código abierto es una forma estupenda de aprender, enseñar y, en general, mejorar el software del que dependen muchas personas.

Se ve bien en tu currículum y es una forma estupenda de demostrar que tienes pasión, dado que haces algo bueno por lo que nadie te paga. Baste decir que no hace ningún daño comentar que eres colaborador. Sin embargo, asegúrate de evitar cualquier situación incómoda si te hacen una pregunta para saber más.

Algunas cosas a considerar al recibir una invitación de entrevista de ingeniero de software senior son:

• Sé conciso al responder a las preguntas y asegúrate de que tu respuesta tome entre 30 y 90 segundos.
• Al responder preguntas de entrevista sobre el comportamiento del ingeniero de software senior, utiliza el formato STAR.
• Mantén un diálogo con el entrevistador, formulando preguntas o manteniendo la interacción conversacional, para así evitar silencios incómodos.
• No estires tus posibilidades más allá de tus conocimientos.
• Prepárate para cualquier pregunta de entrevista técnica para ingenieros de software seniorque te puedan requerir, repasando material que no hayas revisado hace tiempo.