Revisión de código en la contratación de IT - ¿por qué y cómo debe usarse?

Por 21 de abril de 2016 #!30Jue, 16 Abr 2020 11:14:41 +0200p4130#30Jue, 16 Abr 2020 11:14:41 +0200p-11Europa/Varsovia3030Europa/Varsoviax30 16am30am-30Jue, 16 Abr 2020 11:14:41 +0200p11Europa/Varsovia3030Europa/Varsoviax302020Jue, 16 Abr 2020 11:14:41 +02001411144amjueves=269#!30Jue, 16 Abr 2020 11:14:41 +0200pEuropa/Varsovia4#abril 16th, 2020#!30Jue, 16 Abr 2020 11:14:41 +0200p4130#/30Jue, 16 Abr 2020 11:14:41 +0200p-11Europa/Varsovia3030Europa/Varsoviax30#!30Jue, 16 Abr 2020 11:14:41 +0200pEuropa/Varsovia4# Prueba de codificación, Reclutamiento de IT, Entrevista técnica

One of the most important but still ignored aspects of hiring a desarrollador de software is verifying how candidate is dealing with the code and whether is able to express their thoughts with particular programming language. Usually in IT reclutamiento we do it by asking candidate to write some code solving particular problem. Candidate can do it alone or as a pair programming with the recruiter (Hit the bull’s eye with pruebas de codificación in natural environment [case study]). We do it because writing code is one of the most important things developers do on a daily basis. However we should also remember that developers much more often read than write the source code. So we should not forget about verifying if candidate is able to quickly analyse and understand some code snippets. We can simply show some code printouts or (even better) give IDE with some project and ask questions related to what is happening here. That’s where code review challenge is really helpful.

¿Cómo verificar las habilidades de programación de los candidatos durante la entrevista técnica?

Regarding what is said above we see that most of the time during technical interview/ assessment we spend on verifying if the candidate is able to solve some programming challenges or problems. Candidate is focusing on understanding and analyzing the problem and then finding a proper solution. However, we can realize that candidate is forced to think more about “what to do” than “how to do”. When we ask candidate to write a code which will be able to reserve a seat for a flight in some conditions, the goal is to ship the correct functionality, and mostly due to stress and time limitation it’s all the candidate is able to do. Is there any option to reverse this situation and let the candidate focus on “how”? Yes! For the many years when I was actively involved in IT sourcing and hiring developers or architects I was using code reseñas.

¿Qué es la revisión de código?

Revisión del código is a process when programadores verify each other code to find any potential problems, errors or deviations from best practices (if you want to learn more go to Wikipedia). En los últimos años la revisión de código es un elemento imprescindible del proceso de entrega de software. Nos da una gran auditabilidad y una mejor calidad de código, pero también permite un increíble intercambio de conocimientos - la gente puede ahora enseñar y aprender al mismo tiempo, compartiendo experiencias. Pero no quiero convencerte de que hagas cumplir las revisiones de código en tu proceso de desarrollo (que por cierto deberías replantearte si aún no lo estás usando) sino que te muestre por qué y cómo usar las revisiones de código durante la entrevista técnica.

¿Cómo se puede utilizar la revisión de código en el proceso de contratación de TI?

Mostrando el código candidato que ya está escrito y funciona (en su mayor parte) como se esperaba, les dejamos que se centren en la calidad de la solución. Al preguntar simple question “So, what do you think about this code” we change candidate into read-only mode. What is important to mention is that some developers are used to such tasks which they take during exam certifications, etc. and they are looking up for some silly, intentional errors like missing semicolons, incorrect parameters, wrong classes, etc. In my opinion we should use different approach. I always used working code that compiles correctly. I emphasize at the beginning that there are no “certification-like” errors and candidate should focus on best practices, some common problems that are hard to be noticed by automatic tools and can cause serious problems of production.

Ejemplo de desafío de revisión de código

For example in Java that could be invoking thread.run() instead of thread.start() which compiles correctly, tests are passing but we’re not starting new thread which can degradate final performance. We can also check if candidate will notice that some transactional method is invoked outside of the transactional aspect, which can cause serious consistency problems in a base de datos.

¿Cómo evaluar los conocimientos de programación basados en la revisión de códigos?

Basándonos en la primera impresión del candidato podemos evaluar su enfoque de la calidad. Si para nosotros el código es realmente feo y lleno de problemas y el candidato dice algo como "me parece bien" podemos asumir que no ayudará a mejorar la calidad del código en nuestra empresa e incluso la degradará. También es bastante fácil evaluar la experiencia del candidato. Por ejemplo, en unas 60 líneas de código fuente junior los desarrolladores fueron capaces de encontrar alrededor de 4-5 temas. Los desarrolladores con más de 8 años de experiencia fueron capaces de encontrar 10. Y los mejores candidatos fueron alrededor de 15-20 números. El mejor candidato me señaló 2 problemas que no conocía, y cuando estaba escribiendo el código se incluyeron más de 30 problemas.

¿Qué debemos esperar que los candidatos comenten? Lo más importante son los temas mencionados anteriormente, problemas que son comunes para una tecnología en particular y que no son visibles a primera vista. Lo siguiente es la legibilidad. El código tiene que ser limpio, bien estructurado y bien nombrado para que cualquier otro desarrollador (no sólo el autor) sea capaz de entenderlo y cambiarlo. Así que los nombres de los métodos o variables - son significativos, no demasiado largos, etc. ¿Son métodos no demasiado grandes y no contienen demasiada lógica. ¿Son las tecnologías utilizadas en el fragmento una buena elección para resolver un problema particular (por ejemplo, si nuestro código está utilizando operaciones de cadena para construir un XML podemos esperar que el candidato señale que hay muchas bibliotecas que fueron creadas para hacerlo de una mejor manera).

Revisión del código en las campañas de evaluación de DevSkiller

En DevSkiller creemos que la revisión de los códigos debería incluirse en la evaluación de la programación habilidades. Es por eso que la mayoría de nuestras campañas de evaluación contienen ese tipo de problema a resolver. También animamos a las empresas a construir sus propias pruebas de codificación que incluyen el desafío de revisión de código. Es bastante conveniente para la mayoría de las compañías ya que pueden usar su antigua base de código para preparar tal tarea. Sólo tienes que hablar con tu departamento de TI sobre esto e incluirlo en tu proceso de contratación.