La alternativa a la entrevista de pizarra: cómo hacer (por fin) bien las entrevistas técnicas

Las entrevistas técnicas llevan mucho tiempo provocando indignación entre los desarrolladores de software. Su objetivo es evaluar la aptitud para la ingeniería y predecir el rendimiento futuro en caso de ser contratado para el puesto. Suena bastante sencillo, ¿verdad? ¿Por qué entonces tantas empresas tecnológicas, incluidos los gigantes de la tecnología, recurren a métodos de entrevista que los desarrolladores odian de verdad? La entrevista de pizarra es, con diferencia, el método más utilizado.

En este artículo abordamos los siguientes temas:

• ¿Qué es una entrevista de pizarra y qué tiene de malo?
• ¿Cuál es el objetivo de la entrevista técnica?
• ¿Odian los desarrolladores la idea de someterse a pruebas? Conclusiones de nuestro estudio
• 73% de los desarrolladores realizan una prueba de codificación enviada por el reclutador
• 91,9% de los desarrolladores que empiezan a hacer el test lo terminan
• Alternativa de entrevista de pizarra: cómo estructurar su proceso de contratación técnica
• Spartez contratación técnica: estructura
• La entrevista de la pizarra: conclusión

Hemos recopilado más consejos y trucos para las entrevistas técnicas en La guía definitiva para la entrevista técnica.

¿Qué es una entrevista en una pizarra blanca?

Las entrevistas de pizarra son esencialmente pruebas técnicas que dicen muy poco sobre las habilidades reales de codificación. Se pide a los candidatos que inviertan árboles binarios en una pizarra o que recuerden algoritmos de memoria. Citando a un instructor de programación Quincy Larson,

"Desgraciadamente, las prácticas de entrevista en las grandes empresas tecnológicas no son tan científicas. La decisión de contratar o no a un desarrollador suele reducirse a que el candidato se acerque a una pizarra y regurgite algoritmos que no han cambiado desde los años 70, como un mono (clásicamente) entrenado."

En otras palabras, el mayor defecto de la entrevista de pizarra es que no es realista. Tampoco es representativa de las habilidades de codificación de cada uno. Como consecuencia, este estilo de entrevista puede resultar estresante e intimidatorio para el candidato. Incluso los desarrolladores experimentados pueden sentirse intimidados por el proceso e incluso fracasar en este tipo de entrevista.

¿Pruebas?

Max Howell: Swift. Código abierto. Futurismo. Creador de Homebrew. A tiempo completo haciendo código abierto para *you*.

David Heinemeier Hansson: Creador de Ruby on Rails, fundador y director de tecnología de Basecamp, autor de best-sellers del NYT y piloto de carreras ganador de las 24 horas de Le Mans.

Los rompecabezas de las pruebas de pizarra no se parecen al trabajo diario de los desarrolladores: no hay ordenadores ni acceso a materiales de referencia. Este escenario es poco realista y, como tal, dice muy poco sobre las capacidades reales de codificación de cada uno. En Quincy Larson escribió"El único mundo en el que realmente necesitarías poder recordar un algoritmo sería uno postapocalíptico, en el que los discos duros de todos los ordenadores conectados a Internet estuvieran fritos y todas las copias de artículos académicos fundacionales y libros de texto de informática se hubieran reducido a cenizas".

Es muy poco probable que sus desarrolladores trabajen en este tipo de entorno. Para empeorar las cosas, las entrevistas de pizarra tienden a producir equipos homogéneos porque normalmente "discriminar a las personas que ya están infrarrepresentadas en el sector.“

Con toda la mala reputación que están recibiendo, se podría pensar que las pruebas de pizarra son cosa del pasado. Lamentablemente, siguen muy vivas. Hay muchos recursos que enseñan a la gente a superar las entrevistas de pizarra, ya que, como hemos dicho, es una habilidad en sí misma.

Por suerte, no todo está perdido.

¿Cuál es el objetivo de la entrevista técnica?

Una vez establecido lo que es la entrevista de pizarra, veamos ahora los objetivos de la entrevista técnica.

• evaluar las capacidades de resolución de problemas
• trabajar juntos para evaluar la adecuación del equipo y la empresa
• centrarse en tareas específicas de su empresa, por ejemplo, en las que está trabajando actualmente su equipo de desarrollo

Echemos también un vistazo a los objetivos del candidato que se presenta a la entrevista técnica.

•  evaluar sus competencias de forma objetiva
• conocer a las personas con las que podrían trabajar
• hacerse una idea de la empresa

A veces se recurre a las entrevistas centradas en la pizarra en lugar de la evaluación técnica (suspiro), que debería preceder a cualquier entrevista. Con el enfoque adecuado para la evaluación de las habilidades técnicas, puede reducir el número de entrevistas innecesarias hasta en 65%. Evaluar las habilidades de programación en una fase temprana del proceso de contratación le permite centrar su tiempo, energía y conversación en los candidatos más prometedores. Por regla general, cuanto mejor sea el proceso de preselección, menos personas necesitarán ser invitadas a una entrevista in situ.

Tanto si se utilizan antes de la entrevista técnica como si se utilizan como entrevista técnica, las entrevistas de pizarra no permiten por sí solas alcanzar todos los objetivos mencionados anteriormente.

LECTURA RECOMENDADA: Cómo hacer una entrevista técnica: 7 consejos para una entrevista técnica

¿Odian los desarrolladores la idea de someterse a pruebas? Conclusiones de nuestro estudio

En el caso de la evaluación de competencias tecnológicas, el diablo está en los detalles. Para los desarrolladores, la idea de que se evalúen sus competencias no es el problema. Es la ejecución lo que provoca la indignación.

¿Pruebas? Recientemente hemos publicado el Informe sobre contratación y competencias técnicas de DevSkiller 2019 basado en más de 112 000 pruebas de codificación realizadas por candidatos de más de 120 países. Disponer de estos datos nos coloca en una posición privilegiada, ya que podemos responder a algunas preguntas importantes y relevantes del sector. He aquí dos de nuestras conclusiones (hay muchas más en el informe, no dejes de consultarlo). 

Tasa de realización de pruebas: 73% de los desarrolladores realizan una prueba de codificación enviada por el reclutador.

91,9% de los desarrolladores que empiezan a hacer el test lo terminan

Los resultados de nuestro reciente estudio sugieren que no todas las evaluaciones de habilidades de codificación son iguales. Según nuestra muestra, casi 92% de los desarrolladores que empezaron a realizar una prueba en nuestra plataforma tardaron en terminarla y enviarla.

Esto sugiere que los desarrolladores no se oponen a la idea de una evaluación de competencias técnicas como tal. Lo que no aprecian es que se les ponga a prueba de una manera que no permita que sus habilidades brillen.

Alternativa de entrevista de pizarra: cómo estructurar su proceso de contratación técnica

There are many alternatives to running whiteboard interviews. Let’s look at the best setup you can use to boost your technical hiring results.

1. Sourcing
2. Screening (with an automated solution)
3. Soft skills interview and technical interview (often on the same day)
4. Offer
5. Hire

First of all, you need to automate your preselection procedure and filter out non-viable candidates way before the interview stage. This way, you only spend the face-to-face time of your IT team on candidates who might be a fit for the position. What happens if you don’t screen out weak candidates? Your results will likely include plenty of time wasted, unnecessary bottlenecks, frustration, productivity losses… That’s just the tip of the iceberg.

Second of all, you should follow your technical screening with a soft skills interview and a technical interview. During the soft skills interview, I strongly recommend asking these preguntas sobre el comportamiento to ask technical candidates.

In the technical interview, you want to use coding interview tasks which meet the following criteria:

• The test is an authentic work sample
• It gives your candidate all of the resources they would normally use at work
• It bases the task on a business problem they will face when they start working for you

One of the best whiteboard interview alternatives is the CodePair feature.

You can find out more about code pairing in one of our articles:  Entrevista de codificación en línea y cómo hacer CodePair a distancia

A word of warning: even if all of the abovementioned elements are present in your process, you still have room for improvement.  Let’s take a look at how Spartez boosted their developer hiring results by moving things around in their process.

Spartez contratación técnica: estructura

1. Sourcing

Spartez hires approximately 20 developers annually. The tech skills they value include Java, JavaScript, .NET, and C++.

2. DevSkiller technical screening

We give everyone a chance to attempt the test. We do not assess people only by CV and years of experience, we care more about their technical skills and depth of experience.”, says Patrycja Kiljańska, Talent Acquisition Specialist at Spartez.

3. Live coding test

Those who pass the initial screening are invited to a live coding test conducted by one of their engineers. This step is optional but some companies prefer to keep it to further decrease the number of on-site interviews.

4. Technical interview

Successful candidates are then invited to a 60-minute technical interview conducted by two Spartez engineers. The interview covers the fundamentals of Java or JavaScript, as well as questions about other technical issues and tasks that Spartez developers face at work.

5. Interview with development managers/the CEO (for senior roles)

This is a typical managerial round covering communication, teamwork, motivation, and product based questions.

Of course, the structure of the technical process at Spartez is only an example of how you can set up your technical screening process.

La entrevista de la pizarra: conclusión

In a world that runs on code, it makes sense to hire people based on the quality of their code and not other, discrete skills like rote memorization.  As Nate Swanner says, “A better use of the whiteboard may be to dig deeper into a candidate’s GitHub project, and encourage them to sketch their concept for how an app or tool works and can scale. Ask them about their own projects; if they can’t relate how their own projects work–and accept criticism about them–that might provide a better idea of who they are and how they work than inverting a binary tree ever could.” I couldn’t agree more.

If you want to make a change and assess coding skills objectively, take a look at our catálogo de pruebas de codificación.