cibernoticias EXPRESS

La cara oculta de las noticias

Programadores que no programan

A raíz del artículo Programando para la Administración Pública, he recibido muchos correos y llamadas de colegas que se sentían plenamente identificados con el relato. Incluso ha habido quienes han indentificado a algunos de los aludidos y que no han dudado en contactarme con más historias sobre esta gente ya fuera del ámbito de la Administación.

Pero algo que me ha resultado francamente interesante es que, además de los comentarios de otros programadores, he tenido la oportunidad de hablar con quienes están al otro lado: consultoras y empresas. Responsables de algunos importantes departamentos de Recursos Humanos a nivel nacional me comentaban que el panorama actual a la hora de contratar personal es desolador: casi ninguno de los candidatos que se presentan como programadores son capaces de escribir algún tipo de código. Esto significa que, en muchas ocasiones, la demanda del sector obliga a destinar recursos sin la formación mínima que el cliente solicita, algo que la mayoría de estos, ha asumido con resignación.

Esta afirmación no me resulta nueva. Los años de experiencia me han llevado a estar numerosas veces presente en varios procesos de selección tanto a un lado como a otro de la mesa: cuando me ha tocado entrevistar a un programador para cubrir un puesto en mi empresa, muchas veces he dudado sobre si el Currículum que he leído corresponde realmente con la persona que tengo delante: todo lo que por escrito eran conocimientos sólidos, en la práctica pasan a ser nociones sobre algo que ha leído en Internet.

Como este tema ha llamado mi atención, me he puesto a investigar un poco sobre los procesos de selección y la información que obtienen las consultoras y empresas sobre el candidato en cuestión.

Algunas de las organizaciones más importantes de este país en términos tecnológicos, tienen un proceso de selección muy duro que dividen en varias entrevistas tanto teléfonicas como presenciales. En ellas, además de evaluar el perfil académico o los méritos, nos piden resolver algunos problemas técnicos para evaluar nuestros recursos. Es el sistema por ejemplo de Google, Softonic o Tuenti entre muchas otras.

Estas pruebas son las que más me han interesado ya que permiten medir con cierta precisión el nivel real del solicitante. Y el resultado es, tal y como me habían advertido, inquietante. Según una estadística rápida, de cada 10 candidatos que solicitan un puesto en la empresa, 7 de ellos no son capaces de escribir el algoritmo más simple en aquellos lenguajes en los que se definen como expertos.

Elena, jefa del departamento de Recursos Humanos de una conocida consultora, me confiesa que criban más del 80% de las candidaturas con una simple prueba sobre papel:

– Le pedimos al candidato que seleccione un par de lenguajes de programación de entre aquellos que figuran en su CV y que escriba para cada uno un programa capaz de contar de 1 a 100. Como entendemos que es una prueba muy sencilla, solo facilitamos lápiz, papel y 5 minutos. De cada 10 entrevistados, 3 comienzan a excusarse y no realizan la prueba; otros 3 la comienzan pero no la resuelven en el tiempo facilitado. Con suerte, otros 3 la completan correctamente porque realmente saben lo que hacen y, finalmente, la persona restante se siente ofendida en su orgullo y solicita abandonar la entrevista. Esto en una fría estadística supone un 70% de fracasos. Algo alarmante si tenemos en cuenta que tratamos con licenciados, ingenieros o graduados en Ciclos Formativos.

Javier, desde su departamento en otra conocida empresa española, me facilita datos similares: a los aspirantes les hacen una prueba desde casa para evaluar su habilidad en aquellos lenguajes que ellos mismos escogen. Amablemente, me hace llegar uno de los enunciados para un puesto de ingeniería de Front-End: un PDF en inglés con el enunciado de un problema en el que tenemos que usar Javascript orientado a objetos. La prueba está planteada para ser resuelta en un par de horas, espacio de tiempo que personalmente estimo muy optimista. Se evalúa la compresión del problema, la calidad del código entregado y la eficiencia del algoritmo implementado.

– Tenemos diversos modelos de examen creados por nuestro equipo de ingenieros. Generalmente damos un par de horas a los candidatos para que realicen el ejercicio en aquel momento que estimen oportuno. Sólo tienen que solicitarlo y se les envía casi de inmediato; incluso fuera del horario de oficina. De cada diez propuestas que enviamos, solo recibimos 2 ó 3 respuestas. De los archivos recibidos, podemos concluir con que prácticamente nadie ha completado la prueba en el tiempo estimado: la media de tiempo para la entrega es de tres horas, por lo que nos hemos decidido por valorar más el resultado que la velocidad en ejecución. Nuestro criterio de evaluación se basa en la calidad del algoritmo y en la estructura del código: si el programador aspira a formar parte de un equipo de desarrollo, su código tiene que ser fácilmente interpretado por el resto de colegas. No queremos personas insustituibles por el simple hecho de que sus aplicaciones sean inaccesibles para el resto del equipo. En definitiva, de cada 10 propuestas enviadas, tramitamos para una segunda fase de 0 a 1.

Para aquellos interesados en ojear el problema, pueden descargarse el PDF desde aquí.

Me queda claro que las grandes corporaciones han establecidos unos eficaces filtros para seleccionar a su personal. El dato, sin embargo, es escalofriante: la mayoría de aspirantes no son capaces de resolver problemas triviales desde la comodida de su propio salón. Me pregunto si la situación es similar en empresas más modestas, por lo que contacto con algunas pymes para recoger más datos.

Juan, director de Marketing de una empresa poco conocida pero responsable de las más importantes tiendas de comercio electrónico de este país, me comenta que no disponen de mecanismos para evaluar candidaturas. Hasta ahora, se han basado en la evaluación de CVs a través de conocidos portales de empleo y de una entrevista personal. Ni siquiera confían en las consultoras. Cuando le pregunto qué resultado le ha dado hasta ahora su sistema, no puede esconder frustración.

– Mal; no has ido muy mal. Necesitamos analistas y desarrolladores capaces de escribir código PHP orientado a objetos. Ocasionalmente, necesitamos implementar mejoras en nuestra plataforma o replicar alguna de nuestras tiendas con éxito para un nuevo cliente. Hemos puesto diversos anuncios y se nos han presentado programadores con un perfil académico altísimo; sin embargo, en la práctica diaria del trabajo, no terminan siendo resolutivos: en muchos casos nos hemos encontrado con informáticos que no son capaces de leer un código y trabajar sobre él. Se pasan las mañanas escondidos tras sus monitores haciendo como que escriben cientos de líneas; sin embargo, al final de la jornada, el trabajo continúa como al principio. A veces, cuando no saben cómo resolver algo, sugieren cosas tan radicales como reescribir todo el código; da igual que se trate de un framework con más de un millón de líneas o un CMS utilizado por miles de usuarios con éxito. La solución del programador mediocre es volver a reescribirlo todo: al final, reinvetamos la rueda tantas veces como damos de alta en la Seguridad Social a un nuevo miembro en el equipo.

Es cierto; estoy plenamente de acuerdo con Juan y la reescritura de código: la solución rápida parece que es siempre rehacerlo todo. Por lo general, no estamos hablando de software mal escrito, sino de programadores que no poseen los conocimientos técnicos suficientes para entender cómo funciona.

Mi último contacto es un empresario madrileño dedicado por entero al mundo de los cruceros online. Se trata de un señor de mediana edad al que he tuve como alumno hace un par de años. Yo sabía que realizaba pruebas a los candidatos a los que entrevistaba, por lo que su opinión me resultaba muy interesante.

– Hace tiempo leí un artículo de un señor al que citabas en tus clases de informática, Jeff Atwood. En él, comentaba cómo era cada vez más frecuente encontrar a programadores titulados incapaces de escribir una sola línea de código o realizar una operación aritmética básica. Como ya había tenido problemas con un par de empleados, decidí coger un ejemplo de ese artículo para evaluar a los futuros candidatos. Se trata de escribir un simple programa que imprima en pantalla los primeros 100 números. Si un número es múltiplo de 3, se escribe “Fizz” en su lugar. Si el número es múltiplo de 5, se escribe “Buzz”. Si el número es múltiplo de ambos se escribe “FizzBuzz”. El único requisito es que el aspirante teclee el código delante de algún empleado para que lo supervise. Con esta prueba tan sencilla, he conseguido evitarme sorpresas.

Conocía el ejemplo; revisé el artículo de Atwood y busqué la referencia. Mirando en los comentarios del post, lo más sorprendente es que muchos erraron la respuesta: estamos hablando de que parte del público objetivo de un blog puramente técnico, tampoco supieron dar con una respuesta óptima desde la tranquilidad de su casa. Para aquellos lectores no programadores, el problema planteado puede resolverse en un par de minutos; al final del post, he puesto un par de soluciones para PHP y Javascript.

En definitiva, las conclusiones de algunos responsables de Recursos Humanos tanto de grandes empresas como de pymes, son cuanto menos inquietantes: un alto porcentaje de los programadores titulados que se presentan a un proceso de selección no son capaces de escribir el más simple de los programas en aquellos lenguajes en los que dicen ser expertos. Puedo entender que para algunos, escribir un algoritmo sobre un papel puede ser antinatural: cuando yo mismo lo intento durante mis clases, me doy cuenta de que a veces no recuerdo la sintaxis correcta de algún comando: parece que por lo general, nos defendemos mejor frente a un teclado que sobre una pizarra. También entiendo que la presión del momento puede jugarnos una mala pasada y hacernos quedar en blanco. Pero al fin y al cabo, para conseguir un trabajo, en la mayoría de especialidades tendremos que realizar algún tipo de prueba, por lo que esto no debe ser una excusa.

Jeff Atwood concluía su artículo con un párrafo que me parece inmejorable y que paso a transcribir íntegramente:

“Al menos, los malos programadores pueden ser reeducados; los no-programadores no son sólo inútiles, sino que también restan valor a los profesionales de su alrededor. Deben ser erradicados, comenzando con un simple test que debería formar parte de todo proceso de selección.”

Y ahí encontramos otro problema muy común en las empresas: ya que el rendimiento de la media de programadores en plantilla es limitado, se precisan más recursos para cubrir un proyecto. Si a esto sumamos que los presupuestos suelen estar limitados, cuanto mayor es el número de desarrolladores, menor es el salario que percibe cada uno. Finalmente, el empresario establece un rango salarial en función a su experiencia que termina modificando el mercado. Los sueldos tienden a la baja y los equipos al alza: hay muchas ofertas, pero casi todas mal remuneradas.

Solución a los problemas

En Javascript, legible:

for( var x = 1; x < 101; x++ ){
  if( x % 15 === 0 ){
    console.log( 'FizzBuzz' ); // 15 es el mínimo común múltiplo de 3 y 5
  } else if( x % 3 === 0 ) {
    console.log( 'Fizz' ); // Número múltiplo de 3
  } else if( x % 5 === 0 ) {
    console.log( 'Buzz' ); // Número múltiplo de 5
  } else {
    console.log( x );
  }
}

En PHP, legible:

for( $x = 1; $x < 101; $x++ ){
  if( $x % 15 === 0 ){
    echo "FizzBuzz\n";
  } elseif( $x % 3 === 0 ) {
    echo "Fizz\n";
  } elseif( $x % 5 === 0 ) {
    echo "Buzz\n";
  } else {
    echo $x . "\n";
  }
}

Además de estas, hay muchas otras. Podemos, por ejemplo, compactar el código para reducir su tamaño a costa de su legibilidad. Por ejemplo, en Javascript podríamos eliminar algunas llaves:

for( var x = 1; x < 101; x++ ){
  if( x % 15 === 0 ) console.log( 'FizzBuzz' );
  else if( x % 3 === 0 ) console.log( 'Fizz' );
  else if( x % 5 === 0 ) console.log( 'Buzz' );
  else console.log( x );
}

O simplificar los condicionales en un código más elegante:

for( var x = 1, y; x < 101; y = "" , x++ ){
  if( x % 3 === 0 ) y += 'Fizz';
  if( x % 5 === 0 ) y += 'Buzz';
  console.log( y || x );
}

Si queréis participar con más soluciones en otros lenguajes o mejorar los ejemplos propuestos, podéis escribir vuestro código en los comentarios indicando el tiempo que os ha llevado. Puede ser una prueba personal interesante para comprobar si pasaríamos o no algunas de las entrevistas aquí planteadas.

16 enero, 2011 - Posted by | ARTÍCULOS de OPINIÓN | ,

Aún no hay comentarios.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: