preguntas de entrevista para desarrolladores Java: todo lo que un ingeniero de software necesita saber

La siguiente guía se basa en una mesa redonda en la que participaron Alexander Shvarz, Jefe del Equipo de Ingeniería de Software de EPAM; Roman Gordiienko, Arquitecto de Soluciones II; Tair Mustafaiev, Arquitecto de Soluciones I; y Arkadii Suslo, Director de Ingeniería de Software.

Para desarrolladores Java y otros ingenieros de software, una de las partes principales del proceso de entrevista con EPAM Anywhere es la entrevista técnica.

Antes de entrar en detalle sobre las preguntas de esta entrevista, nuestros candidatos han pasado por:

• Preselección del perfil que incluye la revisión de la solicitud y pruebas en línea con ejercicios prácticos algorítmicos y lógicos diseñados para poner a prueba determinadas competencias y habilidades básicas que son requisitos para el puesto.
• Entrevista general que suele ser una videollamada con un especialista en adquisición de talentos. Los candidatos tienen la oportunidad de presentarse, compartir su experiencia profesional, sus responsabilidades previas, asi como las tecnologías y el tipo de proyecto en el que están más interesados en trabajar.

Con base en esta información, el entrevistador selecciona las preguntas para la entrevista técnica. Es posible que estas preguntas de entrevista sean sobre concurrencia, multihilos, colecciones, entre otros temas.

Además, el entrevistador querrá saber más sobre su experiencia con frameworks y otras herramientas, tanto teorica como practica, por lo que le proporcionará un ejercicio práctico para resolver; lo que no tomará entre 15-20 minutos. En total, una entrevista técnica para ingenieros de software Java pude llegar a durar hasta 1,5 horas.

También debe saber que otra área que el entrevistador tratará durante la entrevista es una evaluación de su capacidad para resolver problemas y otras habilidades interpersonales clave.

A continuación, daremos un vistazo a ejemplos reales de preguntas de entrevista en empresas que contratan desarrolladores Java.

El objetivo en esta fase es evaluar:

• Conocimiento de conceptos de programación orientada a objetos
• Comprensión de la diferencia entre interfaces y clases
• Concepto de multi herencia
• Comprensión de los principios y la lógica de Java
• Conocimiento de Java 8, sus actualizaciones y ventajas
• Conocimiento de la compatibilidad retrocompatibilidad y su función

Ahora, ¿qué preguntas específicas podrían formularse durante una entrevista de trabajo como programador?

¿Qué diferencias se encuentran entre interfaces y clases?

Para comenzar, es posible que se le pida describir las diferencias entre interfaces y clases. Aunque esta pregunta pueda parecer trivial, los candidatos no siempre logran responderla con claridad. La mayoría responde que una interfaz tiene un contrato o una firma como métodos, mientras que la clase facilita la implementación de éstos métodos. En resumen, la diferencia que señalan es: las interfaces no tienen implementación, mientras que las clases, al menos parcialmente, sí tienen. Si éstas son las respuestas, el entrevistador puede formular la siguiente pregunta: ¿Sucede lo mismo en Java 8?

Java 8 incluye una nueva característica: métodos por defecto, lo que permite que una interfaz incluya, no sólo un contrato, sino también algún tipo de implementación, disipando la diferencia entre estas dos estructuras. En respuesta, los candidatos suelen decir que sigue existiendo diferencia porque sólo es posible extender una única clase abstracta en tanto que es posible implementar multiples interfaces. Lo que nos lleva al siguiente punto.

Los candidatos que señalan las diferencias entre una interfaz y una clase suelen decir que una tiene posibilidades de multi implementación, mientras que la otra no. En realidad, en la práctica, esto no es una diferencia sino una consecuencia o manifestación de una diferencia subyacente a ambos conceptos. La real diferencia entre ambos tiene que ver con... el estado.

La diferencia conceptual entre interfaces y clases es que una clase (aunque sea abstracta) tiene un estado, mientras que una interfaz no. A continuación se resumen estas diferencias:

OOPs interfaz vs. clase abstracta

Una vez cubierta esta parte puede que el entrevistador enfoque la entrevista exclusivamente en preguntas relacionadas con el problema del diamante.

¿Qué problemas se pueden encontrar dentro de la multi herencia?

Inicialmente, no se ofrecía multi herencia, por lo que el problema del diamante no se presentaba. Con la aparición de los métodos por defecto, puede que se presente el problema del diamante. Por lo tanto, es posible que se pregunte al programador qué ocurrirá si tenemos dos interfaces no relacionadas que tienen un método por defecto con la misma firma pero diferente implementación, y queremos implementar estas dos interfaces en una clase.

A lo que se pide resolver este problema.

Si el candidato entiende bien cómo funciona Java, sabrá que el problema se encuentra a nivel de la compilación, por lo que devolverá un error de compilación. Una solución es anular este método en la clase. Otra opción es utilizar la composición: si se tiene una clase que implementa una interfaz, es posible intentar representarla como una clase interna dentro de otra clase.

¿Por qué se necesitan métodos por defecto y pueden éstos anular un método Object?

La primera pregunta que puede hacerse durante una entrevista, referente a los métodos por defecto, es: ¿por qué se incluyó este concepto? Las respuestas tienen que ver con el concepto de compatibilidad con versiones anteriores en Java 8. La posibilidad de activar métodos por defecto en la interfaz es la característica que ayudó a mantener la compatibilidad con versiones anteriores.

Si la discusión con el candidato llega hasta este punto, la última pregunta que puede plantearse durante la entrevista es sí los métodos por defecto de la interfaz pueden anular algunos métodos de la clase Object, y el porqué no.

Si se crea un método por defecto con la misma firma, por ejemplo, similar en la clase Object, el comportamiento que es heredado de otra clase cambia. Esto viola el principio básico que distingue las interfaces de las clases.

Estas preguntas teóricas están diseñadas para cubrir fundamentos básicos que durante la entrevista se le realizarán al programador senior en orden de complejidad gradualmente, desde la mas básica hasta la mas compleja.

Esta preguntas de entrevista tienen el objetivo de evaluar:

• Conocimiento de las mejores prácticas de diseño de almacenamiento de datos
• Experiencia práctica con bases de datos relacionales
• Experiencia con NoSQL
• Comprensión de las versiones y compatibilidad con versiones anteriores
• Comprensión de la lógica de estratificación: qué debe estar en la aplicación y qué es necesaria a nivel de base de datos

Otras preguntas básicas de la entrevista relacionadas con este tema pueden referirse al escalado horizontal de las bases de datos relacionales, problemas asociados y formas de cómo resolverlos. Las soluciones incluyen la replicación de varias instancias, la replicación Maestro-Maestro o el uso de bases de datos NoSQL, que son mucho más avanzadas en términos de escalado horizontal.

¿Cómo se pueden encontrar duplicados en una base de datos relacional utilizando SQL?

Si una base de datos relacional ya contiene datos no únicos y no hay forma de implementar ninguna restricción, el entrevistador puede pedir al candidato que sugiera una forma de encontrar duplicados utilizando SQL.

A nivel de servicio, hay una forma de resolver esto. El entrevistador puede que sugiera las siguientes condiciones adicionales: añadir una columna (por ejemplo, el tamaño de la población de una ciudad) y cambiar el nombre de otra (por ejemplo, la provincia en la que se encuentra esta ciudad).

En este punto de la entrevista, el entrevistador está evaluando la capacidad del candidato para trabajar con la base de datos de forma que sea compatible con versiones anteriores. Es probable que un candidato sin experiencia en la migración de bases de datos y esquemas se limite a renombrar o añadir una columna. Hacerlo de esta manera causará problemas de compatibilidad, ya que la columna renombrada no será accesible para la versión anterior de la aplicación. Por lo que se le pedirá al candidato que elabore un plan de recuperación. Una respuesta esperada para resolver este caso es: si se debe renombrar algo, es mejor añadir una nueva columna y mantener la antigua durante varias versiones, hasta que sea posible eliminarla.

De la misma manera, si una nueva columna es añadida, no debe ser eliminada en caso de tener que volver a una versión anterior, ya que en algún momento se tendrá que volver a una versión avanzada de la aplicación.

¿Cómo diseñar tablas para almacenar la estructura de herencia?

También se le puede pedir a un candidato que diseñe tablas para almacenar la estructura de herencia, por ejemplo, una persona que es, al mismo tiempo, estudiante y profesor. Algunos de los campos son los mismos, otros difieren. Hay varias maneras de manejar estos casos, cada una con sus pros y sus contras. En este caso, se puede tener una única tabla con un discriminador o varias tablas.

El objetivo es evaluar:

• Comprensión de los principios de la arquitectura de microservicios
• Conocimiento de los pros y los contras de los microservicios
• Conocimiento de los patrones clave relacionados con los microservicios

Esta bloque de preguntas contiene en su mayoría preguntas de entrevista para desarrolladores Java senior.

¿Cuáles son los pros y los contras de los microservicios?

El entrevistador puede que pida identificar las características generales y los principios básicos de los microservicios. También puede pedir al candidato que comparta su experiencia previa con microservicios y su opinión sobre las ventajas y desventajas de este concepto. El entrevistador querrá saber hasta qué punto el candidato comprende la importancia de cada ventaja y desventaja y en qué se diferencian los microservicios de una arquitectura monolítica.

Los pros a mencionar:

• La arquitectura de microservicios es altamente escalable, de forma flexible
• Es fácil de entender
• Ayuda a evitar el aislamiento de fallos
• Garantiza una recuperación rápida en caso de diseño y uso correctos de la orquestación
• Ofrece un despliegue más rápido si la CD está bien configurada y ajustada

Los contras a mencionar:

• Existe una comunicación compleja entre servicios (cuando se requiere de código HTTP, una cola, etc.)
• Más servicios requieren más recursos
• La depuración y las pruebas de extremo a extremo son más complejas en los microservicios
• El despliegue puede ser un reto si el equipo no está del todo maduro en términos de prácticas DevOps, y no puede configurar el proceso de CD correctamente

¿Cuáles son los patrones comunes relacionados con los microservicios?

Otra área importante de conocimiento en relación con los microservicios son los patrones. Es importante que el candidato vaya más allá de API Gateway y Circuit Breaker y cubra más patrones relacionados con la arquitectura de microservicios.

Los patrones se dividen en diferentes categorías: patrones de descomposición (descomposición de monolitos en microservicios), patrones que permiten la integración entre servicios, patrones relacionados con bases de datos, patrones para transacciones, observabilidad de estados de microservicios, etc.

También se espera que los candidatos senior demuestren al menos conocimientos generales de registro, monitoreo y alertas. Algunos aspectos esenciales son:

• Registro: herramientas, pilas ELK y Splunk, cómo funciona la agregación de registros y cómo se implementa en general.
• Monitoreo: aquí, el entrevistador espera oír hablar sobre automatización, captura y medición de diversas métricas (por ejemplo, solicitudes de latencia, trazado abierto), posibles cuellos de botella y formas de abordarlos de forma rápida y eficiente.
• Alertas: con respecto a este patrón, que está relacionado con el monitoreo, es importante hablar de automatización, herramientas y cómo implementar las alertas.

El objetivo aquí es evaluar:

• Lógica y forma de pensar
• Complejidad de las soluciones propuestas
• Capacidad para tomar decisiones intuitivas
• Conocimiento de las estructuras de datos

Ejercicio:

• Se tiene una clase Pojo
• Tiene dos campos: valor y longitud, así como getters y setters
• Los getters y setters del segundo campo están comentados
• Se debe utilizar esta entidad como clave en el HashMap
• Además de usarlo se debe guardar el Integer Object
• Para Pojo se establece setValue "abc" y se graba en el HashMap
• Luego, setLength e intentar recuperarlo

Pregunta: ¿cuál es el resultado obtenido?

Esta pregunta es bastante sencilla pero al mismo tiempo compleja. Los candidatos de cualquier nivel de antigüedad siempre tienen algo diferente que ofrecer con sus respuestas.

Los candidatos suelen pensar que la respuesta de este ejercicio práctico es "1". Su argumento es: hashcode equals no está sobrescrito y se utilizará desde la clase básica, Object, que no tiene campos mencionados. Ante este tipo de respuestas, el entrevistador puede preguntar: ¿cómo se puede cambiar la clase Pojo para que este código funcione en el lado del cliente?

La mayoría de los candidatos sugieren definir equals y hashcode. Una vez que hemos definido equals y hashcode, siempre obtendremos "null". Null será devuelto sólo porque hemos cambiado la longitud, y un objeto es mutable.

Aunque no es una pregunta difícil, algunos candidatos necesitan analizar varias veces el código, pasar por todos los puntos, calcular, y ver que el hashcode se modificará y no será posible encontrar un Objeto.

Lo que nos lleva al problema de la inmutabilidad, y al objetivo de identificar las formas de utilizar Pojo de forma segura. Un candidato podría sugerir el uso de finales al principio, porque no hay modificador de acceso.

Cuando esta clase se vuelve inmutable, el ejercicio práctico cambia ligeramente: en lugar del valor de cadena, se inserta un objeto mutable, por ejemplo, Date u otra clase mutable. Las nuevas preguntas que surgen son: ¿qué pasará ahora, cómo funcionará, se presentará algún problema?

El candidato puede sugerir que se utilice la copia o la clonación. Si es así, puede ser una buena idea probar con la clonación y las excepciones según sea necesario. Todos los casos son diferentes y los candidatos también pueden resolver esta tarea de forma diferente.

Con estas preguntas es como el entrevistador cubre las estructuras de datos utilizando el ejemplo de HashMap, quizás el ejemplo más utilizado. Si un candidato está dispuesto a hablar de problemas algorítmicos, el entrevistador puede sugerir revisar los matices de HashMap.

En cualquier caso, cualquier pregunta avanzada de una entrevista dentro de un ejercicio práctico está diseñada para responder a la experiencia y el interés del candidato. El objetivo del entrevistador no es tanto detectar lagunas de conocimiento como revelar las áreas que le interesan y evaluar la profundidad y amplitud de sus conocimientos.

Los entrevistadores afirman que la disposición para analizar al código es una de las aptitudes clave a evaluar. Esto ayuda a analizar cómo un candidato se enfrenta a un problema desconocido o a una nueva tarea en el futuro.

Por supuesto, muchas otras preguntas pueden presentarse durante una entrevista que son igualmente importantes, como aquellás relaciondas con Spring, REST, Cloud, las características de Java 8, concurrencia y multihilo.

Por ejemplo, otras preguntas avanzadas para un entrevista con un programador pueden referirse a:

• CI/CD
• Enfoque de las estimaciones
• Trabajo en equipo
• Prácticas de refactorización
• Enfoques y cultura de pruebas

Además, las preguntas de entrevista con un programador pueden ir más allá de las tecnologías y las herramientas en un esfuerzo por descubrir el perfil T-shaped del candidato.

Esperamos que este resumen ayude a comprender mejor las preguntas que se pueden hacer a los ingenieros Java durante una entrevista técnica. Si está buscando oportunidades para programadores Java, consulte nuestras ofertas laborales disponibles a continuación.