synthroid taking instructions

Inicio > Gestión TI > Programadores que no programan

Programadores que no programan

Sábado, 11 de Febrero de 2017 Dejar un comentario Ir a comentarios

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:

  1. 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.
  2. 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.

  3. 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.
  4. 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 quieres participar con más soluciones en otros lenguajes o mejorar los ejemplos propuestos, puedes escribir tu código en los comentarios indicando el tiempo que te ha llevado. Puede ser una prueba personal interesante para comprobar si pasaríamos o no algunas de las entrevistas aquí planteadas.

Fuente: EtnasSoft

Comparte y diviertete:
  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • BarraPunto
  • Bitacoras.com
  • BlinkList
  • Blogosphere
  • Live
  • Meneame
  • MSN Reporter
  • MySpace
  • RSS
  • Suggest to Techmeme via Twitter
  • Technorati
  • LinkedIn
  • email
  • FriendFeed
  • PDF
  • Reddit
  • Wikio IT
  • Add to favorites
  • blogmarks
  • jUNIOR

    En java

    public class Conteo1 {
    public static void main(String[] args)

    {

    int c=0;

    int m3=0;

    int s3=0;

    while (c<100)

    {

    c++;

    if (c%3==0)
    System.out.println("FIZZ");
    if (c%5==0)
    System.out.println("BUZZ");
    if (c%5==0 && c%3==0)
    System.out.println("FIZZBUZZ");

    {

    m3=c;

    System.out.println(":"+m3);
    }

    }

    }

    }

  • Fabian

    //Javascript:

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

    //95 Caracteres

  • Decio Rodríguez

    # En python
    for i in xrange(1,101):
    .desc = ‘ ‘
    .if i%15 == 0:
    ..desc = ‘FizzBuzz’ # divisible por 15 FizzBuzz
    .else:
    ..if i%3 == 0:
    …desc = ‘Fizz’ # divisible por 3 Fizz
    ..else:
    …if i%5 == 0:
    ….desc = ‘Buzz’ # divisible por 5 Buzz
    .print i, desc
    # Coloqué un punto “.” por cada tab pues no se ve, el sangrado es obligatorio

  • Nightcrawler

    Amigo en parte tienes mucha razón, en Guatemala es muy común esa practica de ofrecer salarios bajos, pero actualmente estoy en una empresa donde si se opto por ofrecen salarios muy competitivos y optamos por hacer pruebas un poco mas complejas, lastimosamente no hubo candidato que las superaras, le bajamos nivel en mucho y el resultado no fue muy prometedor. En resumen se ha vuelto tan popular el tema de la tecnología que todos quieren decir que son conocedores, se de colegas que usan algún CMS y creen que configurarlo y publicarlo es programación.

  • alex Fernandez

    for (var i = 1; i <= 100; i++) {

    if (i % 15 == 0) {
    console.warn("FizzBuzz");
    continue;
    }

    if (i % 3 == 0) {
    console.warn("Fizz");
    continue;
    }

    if (i % 5 == 0) {
    console.warn("Buzz");
    continue;
    }
    console.warn(i);
    }

    leerlo tomo mas tiempo que el desarrollo…

  • Luis Daniel Sauceda Alonso

    EN VBA

    Sub FIZZBUZZ()

    With Hoja1
    For i = 1 To 100
    If i Mod 3 = 0 And i Mod 5 = 0 Then
    .Cells(i, 1) = “FIZZBUZZ”
    ElseIf i Mod 3 = 0 Then
    .Cells(i, 1) = “FIZZ”
    ElseIf i Mod 5 = 0 Then
    .Cells(i, 1) = “BUZZ”
    Else
    .Cells(i, 1) = i
    End If
    Next i
    End With

    End Sub

  • ebra sca

    En Scala me llebo 1 minuto.

    (1 to 100) map (x => (x % 3, x % 5) match {
    case (0, 0) => “FizzBuzz”
    case (0, _) => “Fizz”
    case (_, 0) => “Buzz”
    case (_, _) => x
    })

  • Rici

    En C++:

    #include
    using namespace std;

    int main()
    {
    for (int i=1; i<=100 ; i++)
    {
    if ( i%3==0 && i%5 ==0)
    cout<<"fizzBuzz";
    elseif ( i%3==0 )
    cout<<"Fizz";
    elseif ( i%5==0 )
    cout<<"Buzz";
    else
    cout<<i;
    }
    }

    3 minutos. Conocimientos necesarios? Una simple asignatura de primero de carrera.

  • luis

    for($x=1; $x<=100; $x++)
    echo (($x%15==0)?"fizzBuzz":(($x%3==0)?"fizz":(($x%5==0)?"buzz":$x)))."”;

    4 mins.

  • Igochan

    Jejeje, hace unos años estaba trabajando de Arquitecto de integración de sistemas de una importante empresa tecnológica especializada en búsqueda de empleo. Yo dejaba el empleo pero me dediqué a buscarme un sustituto. En lugar de hoja y papel les dejaba a solas en una sala con un portátil con un proyecto completamente configurado y con conexión a Internat. Les pedíamos ciertas modificaciones simples: ordenar una lista de elementos (para que utilizasen un Collections.Sort), mapear una entidad de Hibernate, hacer un simple traspaso de variables (quiero que lo que está en la Collection a se pase a la Collection b y viceversa…) Las estadísticas son más o menos las mismas, un indignado que no quiso hacerlo, uno que le dolía la cabeza (sí, parece mentira pero lo dijo), otro (profesor de universidad) que no daba pie con bola… Al final no se contrató a nadie. Los resultados de las pruebas fueron decepcionantes, y estamos hablando de gente que decía ser Arquitecto con años de experiencia pero que cuando le pedías que te ordenase una lista de elementos se quedaba en blanco.

  • maseo

    Hola, muy interesante este articulo. desafortunadamente solo muestra un lado y es el de las empresas. me gustaria dar mi punto de vista ya que soy programador.

    en el articulo se dice que las empresas estan adoptando el modelo de google al momento de contratar. algo que es completamente absuro y sinico, debido a que un programador en google gana mas de 80.000 dolares al año y un programador en españa no gana ni siquiera el 20% de esto..

    yo soy de colombia de la ciudad de medellin y por experiencia les puedo contar que he hido a muchas entrevistas donde los procesos son muchos y que al final solo ofrecen salarios miseros de 800 dolares o menos. por eso digo yo, si una empresa quiere un excelente programador tambien debe tener un excelente sueldo para que se beneficien ambos, no solo a uno. por eso cuando voy a una entrevista lo primero que yo pregunto es.. CUANTO PAGAN.. a muchas empresas no les gusta esto, pero por mi experiencia prefiero preguntar esto y no estar de prueba en prueba para que al final me digan “felcitaciones has pasado todas las pruebas con exito tu salario mensual sera de millon cuatrocientos (700 dolares)” para concluir solo agrego algo. las empresas de software no pueden aspirar a poner pruebas y pruebas solo por seguir el metodo de google. debido a que no pueden pagar como google. el dia que lo puedan hacer pues ese dia tambien deben tener con que pagar.

    he conocido casos donde programadores pasan las pruebas, pero las empresas no tienen con que pagarles, en ves de eso prefieren contratar no-programadores y asi no tener que pagar tanto, en este caso existe mediocridad de parte y parte, por un lado los no-programadores y por otro lado las empresas que no tienen dinero y contratan a los no-programadores.

    DESPUES QUE NO SE QUEJEN.

  • Interesante descripción del panorama, me resulta muy difícil ver que sea esta la realidad, precisamente tengo un test online pendiente de hacer, de esos que duran dos horas, así que mejor que me prepare para que sean tres y no haga planes para antes. Me ha gustado mucho la investigación y contraste de info de tu artículo. 

  • Pingback: Bitacoras.com()

Top Footer