Hola, llevo un tiempo haciendo entrevistas técnicas y las hice para dos empresas diferentes, aquí me gustaría indicar que cosas evalúo/pregunto en una entrevista técnica:
Comienzo la entrevista explicando quien soy y cual es mi background, donde trabajé y que hago en la empresa actual para la que estoy entrevistando.
Pregunto como le esta yendo en el trabajo actual si tiene y por que busca cambiar, que es lo que le disgusta y que es lo que le gusta (para aprender un poco de los fallidos y aciertos de los demás)
Luego comienzo la evaluación preguntando:
- Estructura de datos (hashmaps, listas, etc.)
- POO (herencia, polimorfismo, sobrecarga, statics en sus variantes, finals en sus variantes).
- Pregunto como funciona la programación reactiva.
- Dependiendo el seniority pregunto sobre Patrones de diseño y por qué se utiliza Singleton y no una clase puramente estática.
Si es para versiones un poco más recientes de java 8+ comienzo a preguntar cosas como:
- Como y dónde utilizar Optionals
- Como funciona la api de streams en java.
- Como funcionan las lambdas
Spring? pregunto por las distintas cosas de spring:
- Spring security
- Spring data, JPA,
- Diferencias entre distintos tipos de controladores (RestController, Controllers para sockets, ETC).
- * Si se requiere hibernates (cosas como que es un orm, como funciona lazy loading, y cual es la diferencia con jdbc templates).
- * si se requiere pregunto cosas de jsp, jsf, thymeleaf
Pregunto si usaron maven/gradle con anterioridad y como funcionan.
Si es requerido pregunto:
- si se consumió algún SOA,
- si se creó algun soa
- como funcionan los wsdl
Luego pregunto si utilizaron microservicios
- Como funciona una API Rest
- Como funciona JWT
- que ventajas tiene jwt con respecto a Http Session y que desventajas
- Si utilizaron GraphQL y como funciona
Luego paso a bases de datos:
- Que bases de datos utilizaron
- Algunas cosas de sql, como joins o que es una vista y cuando utilizarla.
- Si conocen no relacional y como funcionan estas dbs y su diferencia con las relacionales
Luego si es para un architect de microservicios ya pregunto sobre otras cuestiones:
- Utilizaste redis o similar?, cuando se utiliza, como implementarías caché
- Como funciona elastic, cuando usarlo
- Como funciona el patrón pub/sub, colas de mensajes y que problemas podría tener en el orden de recepcion de mensajes y como solucionarlo.
- Como funciona y por qué utilizas circuit breaker
- alguna otra cosa que se me ocurra preguntar en el momento.
Luego paso a testing:
- Conoces que es, como funciona TDD?
- Describime un ejemplo de como sería el proceso de desarrollo utilizando TDD
- Utilizaste JUnit, TestNG, cucumber, mockito?
- Obviamente pido detalles sobre como utilizar dichas tecnologías.
Finalmente agrego preguntas de
- Git
- Git flows
- Pull request
- Tipos de merges de pr como squash
Si se requiere preguntas de aws o agile las agrego al finalizar.
Fin de las preguntas.
En este punto de la entrevista pudieron pasar varias cosas, que el entrevistado sea muy descriptivo y se explaye mucho, en ese caso algunos puntos los salteo (si veo que ya los fue mencionando, y trato de reducir el numero de preguntas a cosas mas dificiles para no tener que preguntar tanto), ya que trato de que las preguntas no duren más de 45 minutos y se pase por todos los temas.
Cuando el entrevistado no conoce alguna tecnologia o respuesta trato de explicarle la tecnología, o darle una respuesta bien resumida para que lo tome de base, se lleve una idea y pueda ampliar luego su conocimiento.
La idea de mi entrevista es hacer un paneo 360 por todos los aspectos de la programación, ver el nivel en cada uno, y lograr que el entrevistado se lleve algo que no sepa de la entrevista y no haya sido solo un set de preguntas, y si me puede enseñar algo a mi mejor todavía.
Luego de las preguntas, doy un feedback de mi percepción técnica aclarando que no es una respuesta de la empresa, sino mi opinión y el feedback que voy a devolver a RRHH para que continuen el proceso, de este modo el entrevistado se va tranquilo sabiendo qué es lo que le dije a RRHH, que luego ya dependerá de la empresa el proceder.
Y como cierre de la entrevista suelo pedir un feedback de la entrevista al entrevistado para saber si le resulto tensa, aburrida, dinámica o cual fue su percepción, para mejorar el proceso de evaluación en un futuro.
Trato en todo momento de ser dinamico, y generar tranquilidad en el entrevistado explicando que ninguna pregunta es bloqueante, ni que el responder mal o decir que no sabe es algo malo sino mas bien que mejora la fidelidad de nuestra imagen de su conocimiento.
Tomo como tip, que las entrevistas no son un examen de escuela, ni la intención es demostrar lo poco medio o mucho que sabe el entrevistado, sino de simplemente recolectar la información de su nivel de conocimiento sin ponerlo nervioso ni torturarlo.
Luego dependiendo del puesto al que aspira hay otras etapas relacionadas a conformar una solución y defenderla.
Yo no soy muy fan de los challenge, aunque son muy ilustrativos consumen mucho tiempo del dev, y me parece injusto que para nosotros poder evaluarlo, le exijamos hacer un challenge.
Saludos.
Si quieren charlar de algo, tienen dudas o lo que sea pueden encontrarme casi siempre en el chat embebido en el foro (que es un irc) o desde un cliente de irc en el canal de #underc0de en No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
