Recomendaciones para contratar personas


(Camilo) #1

Este tema hablaré sobre la forma en que se contratan a las personas, principalmente en la industria digital en general.

El contexto es el siguiente:
Se necesita una persona que pueda hacer X solución con Y tecnología. Entonces la empresa pone un aviso de trabajo y llegan los postulantes.

Normalmente a los postulantes se les ofrece un período de pruebas aproximadamente de 1± semanas. Luego si es apto para el trabajo se le ofrece un contrato fijo y finalmente indefinido, luego de un período determinado.

Con el fin de evitar problemas que pueden dejar un sin sabor para los que se encuentren trabajando junto a las personas postulantes y también los administradores sugiero tomar en cuenta las siguientes recomendaciones:

  • El tiempo de una persona es valioso. Siempre debe ser remunerado
    aunque no cumpliese las expectativas del trabajo. Es recomendable
    definir antes de iniciar el período de pruebas el valor de la hora
    del postulante y cúantas horas debe cumplir.

  • Se deben establecer metas claras y definidas. Idealmente se debe tener una tarea que necesite de los conocimientos que se usarán en el trabajo final al cual se postula. Un proyecto, tarea o investigación que se pueda medir de forma clara si ha cumplido con éxito o no. Personalmente opino que los problemas de programación tipo ACM no son adecuados para medir la experticia del postulante. Hay personas con múltiples proyectos en el cuerpo y no son expertos en algorítmos de listas enlazadas o de ordenamiento. Si bien ayudan no debiesen ser un factor determinante.

  • Las personas con quien trabajará deben tener un rol protagónico en la evaluación del postulante.

  • Finalmente si la persona no cumpliese las expectativas luego del período de evaluación se debe entregar un resumen en cómo y por qué fallo. Además entregar una serie de recomendaciones para que pueda mejorar tanto de habilidades blandas como habilidades duras. Idealmente una pequeña reunión con recomendaciones escritas y anónimas de cómo mejorar hechas por los compañeros de trabajo.

  • Considerar que es muy importante la socialización entre las personas. Conocer más allá del área de experticia es primordial.


(David Lay) #2

Es super interesante el proceso de incorporación de un profesional a una empresa, por muchos motivos, pero principalmente para mi, porque refleja la cultura de cada empresa de una manera poco evidente en otros procesos.

Mis dos centavos:

Recomiendo efusivamente realizar tanto entrevistas personales, entrevistas profesionales y pruebas técnicas. Pueden ser en la misma sesión de una hora o dos.

El objetivo de una entrevista personal es establecer si la persona está motivada y siente curiosidad, junto con lograr una idea básica de su personalidad y su encaje en el grupo.

La entrevista profesional es sobre profundizar en el curriculum, entender su experiencia dentro de un contexto/historia y no solo como hechos y fechas.

La entrevista técnica es para saber si cumple con los requisitos técnicos mínimos para lo que necesitas. Para esto no recomiendo para nada una prueba de papel y lapiz ni una prueba sobre conceptos de la universidad, sino que una sesión cara a cara donde se comparta el teclado y la pantalla solucionando un problema. Lo que quieres averiguar es si sabe lo básico del asunto para lo que lo estás contratando y si está capacitado para aprender lo que necesite, no si conoce cada detalle del área o trivia técnica. Además de esta manera tienes la oportunidad de aprender como esta persona se comunica profesionalmente sobre los problemas cotidianos, por ejemplo, si hace las preguntas correctas ante una situación ambigua.

De separar en dos sesiones las entrevistas y las pruebas, recomiendo hacer la prueba primero para evitar la pérdida de tiempo por ambas partes. De quedar muchos postulantes luego de las pruebas y entrevistas, se podría hacer una segunda ronda de pruebas técnicas más específicas, pero siempre cara a cara (en mi opinión pierdes mucha información dejando a alguien con un papel y lápiz —o un laptop, da lo mismo— solo en una sala).

El periodo de pruebas de varios días (a boleta me imagino) es bien discutible, ya que los perfiles que aceptan estas condiciones son bien muy junior (no saben mucho que esperar), muy senior (saben que es una buena práctica y están predispuestos) o desesperados (no tienen de otra). Esto en sí es un filtro, pero habla un poco de la postura de la empresa frente al mercado laboral, ya que un filtro tan duro deja de lado a personas perfectamente capaces, con habilidades y que pueden ser un gran aporte a la empresa por motivos no profesionales, sino de tiempo. Hay muchos profesionales que buscan cambiarse de trabajo cuando aun están en su empresa actual, otros que participan de varios procesos en varias empresas. Estas forzando una decisión cuando no es necesario.

Completamente de acuerdo con el periodo de contrato fijo. Sea un mes, dos o tres, me parece adecuado para un postulante que ha cumplido con los requisitos previos. Soy más de la idea de un contrato a tres meses, después de todo, a estas alturas ya debieras tener una muy buena idea de quien es profesional y personalmente. En esta etapa es clave que sus pares sean los que le entreguen feedback de manera periódica (un review formal cada semana o quince días) y no sea un jefe con el que solo ha intercambiado emails. Este periodo de pruebas debiera ser en el marco de un proyecto real, ejerciendo el cargo para el que postuló, con todas las responsabilidades que corresponden.


(Javier Chacana) #3

Algo que hemos puesto en práctica es la demostración básica de habilidades/conocimientos con el sencillo ejercicio del Fizz-Buzz. Es impresionante lo mal que han andado algunos


(Camilo) #4

Encontré estos dos artículos sobre el tema

recomiendan que se realice un proyecto de fin de semana pagado.
ejemplo: onda de viernes a lunes con CLP X de paga. Que tenga relación
con el trabajo al cual se postula.

Ejemplo: Para un diseñador web : Realizar una aplicación one page para organizar películas utilizando las tecnologías a b y c.

Luego se realiza una presentación al resto del equipo con la solución y defensa de su forma de implementar la solución.

Me parece una forma muy positiva de evaluar candidatos. Se les otorga dinero (sea o no sea contratado al final). Se ve un trabajo concreto y realista. Además permite mostrar las habilidades técnicas y blandas del candidato.


(David Lay) #5

Me parece muy buena idea. Incluso en alguna ocasión me han asignado un trabajo similar para un fin de semana o un tiempo equivalente. Hubiera sido MUCHO más motivante si hubiera sido pagado, pero el solo ejercicio de mostrar tus habilidades de manera práctica me pareció entretenido y desafiante.

El segundo link es sin desperdicio. Algunos quotes:

###These don’t work:

  • Puzzles and riddles
  • Whiteboard code tests
  • Big O notation quizzes
  • Detailed quizzes about the mystery corners of the language

###These work great (in order of value):

  • Pair program with candidate on an actual issue from your ticket queue (let the candidate drive)
  • Code samples / OSS contributions
  • PAID Sample project assignment (err on the side of paying fairly — say $100+/hour for estimated completion time — if the problem should require 2 hours to complete, offer $200)
  • Review past work / portfolio
  • Read candidate blog, publications, watch candidate talks
  • Ask candidate for input on a real problem you’re currently working on
  • Ask specific questions about software problems and solutions from candidate’s resume

Instead of assessing a candidate’s abilities, engineers often pick stock puzzles (puzzle performance has zero correlation with job performance), whiteboard coding demonstrations (nobody codes on a whiteboard on the job), or CS101 algorithm tests (experienced devs forgot the useless crap they learned in CS101 years ago so they could remember all the algorithms and design patterns they actually use in real-life).


(Guillermo Schwarz) #6

En mi experiencia lo que quieres:

  1. Inteligencia algorítmica. El fizzbuzz problem parece bueno en ese sentido. Yo uso dar vuelta strings porque me he encontrado con la sorpresa de que hay ingenieros titulados que no saben recursividad o que la evitan. Incluso ingenieros con el grado de “gurú” dentro de sus propias empresas. Eso es un síntoma de un problema mayor.

  2. Habilidad para expresar verbalmente lo que piensan. No sirve de nada un ingeniero que actúa como un mudito. El chiste de la mudita podrá ser muy cómico, pero en la práctica en un proyecto en el que el ingeniero sabe que está todo malo y se queda callado, es como para demandarlo por ser incompetente a propósito… si fuera un médico, demandarlo por “malpractice”.

  3. Seguir buenas prácticas: code conventions + code review (o pair programming) + unit tests + DRY + continuous integration + continuous delivery.

Las entrevistas y las pruebas técnicas pueden medir (1) y (2), pero medir (3) requiere trabajar durante un buen tiempo con el victimario (o la víctima, dependiendo del punto de vista).

Además me ha tocado el problema al revés. Empresas que hacen todo lo anterior, pero el nivel de los desarrolladores es más bien bajo, de modo que la mediocridad está estandarizada y se instala por osmosis al resto de los programadores.

Por ejemplo no tienen BD en el PC de cada desarrollador. ¿En serio? Y ¿cómo corres los test unitarios contra la BD? ¿No usas los tests unitarios como tests de integración?

¿Cómo detectas a las empresas que se hacen pasar por empresas bacanes y sólo están posando?

No pueden tener tests unitarios. Les fallan… les fallan… les fallan… y obviamente tienen que abandonar las pruebas unitarias porque no pueden hacerlo. Esa es la prueba fatal, el criterio que no pueden simular… si no tienen tests unitarios sabes que todo el resto es FAKE.


(Guillermo Schwarz) #7

Totqalmenrte de acuerdo, seria absurdo trabajar gratis, sobre todo considerando que generalmente cuando las personas no producen no es porque no sepan, sino porque el proceso de desarrollo está viciado, los requerimeintos son poco claros o cambian demasiado rápido, las tecnologías no están bien definidas o las definen personas sin experiencia o tienen hoyos que son insalvables o están bien definidas, pero estásn completamente expuestas, de modo que hay cero abstracción y ua gran facilidad para cometer errores (error prone)… J2EE v.1 y v.2 son perfectos ejemplos.

Imagino que es dificil decirle a un programador “escribe una query SQL para obetner los empleados cuyo sueldo promedio en los últimos 4 años es superior X palos”. Eso no me muestra nada. Si la escribe mal, será que se le olvidó algo? Si le pido que la escriba en Java, ¿con qué framework? ¿JDBC directo? ¿O el framework que estamos usando ahora?

¿Le explico el framework? ¿Tenemos tiempo para eso? ¿Qué estoy midiendo realmente?

Si le hago preguntas específicas, estoy revelando un problema escencial del proyecto que estamos construyendo: estamos escribiendo muchas queries.

Uno se puede justificar con que el proyecto es muy grande… pero en mi experiencia, si eso pasa, eso significa que tenemos problemas para generar abstracciones. Y nunca he visto una pregunta adecuanda para la medir la capacidad para la generación de abstracciones, lo que es justamente la habilidad que hará que este desarrollador genere un salto cuántico a otro nivel de productividad.

Esto es verdad. Incluso se hace en Microsoft y no dudo que en otras empresas tecnológicas.

El único problema de esto es que las personas que hacen esto deben ser de primer nivel, sino se estandariza la mediocridad.

Y cuando hablo de primer nivel me refiero a su habilidad para generar abstracciones que aumenten la productividad o la escalabilidad…

Acá la gente puede decir cualquier cosa. Desde “me cae mal”, “no calza con la cultura del equipo”… hasta “no entiende las instrucciones”… se supone que el tipo es inteligente, al menos eso debería ser medido en las pruebas, si dudamss que tipo de inteligencia, ¿la inteligencia algoritmica de seguro nos va a ayudar, porque escribirá algoritmos, cierto?

¿En qué podría fallar? ¿No lee los manuales de las tecnologías que estamos usando? ¿No hace unit tests? ¿No entiende los requerimientos? ¿Escribe mucho código repetido?

Un programador promedio escribe entre 10 y 500 LOC diarias, con la desafortunada consecuencia de que si escribe más de 10 LOC, probablemente su trabajo es puro copy and paste.

Supongo que se entiende que no es posible medir si hace copy and paste en una entrevista o una prueba. Además si pasa la prueba, el problema real sería que no midiéramos el copy and paste con CPD en el proyecto, de modo que su copy and paste rampante no sea detectado. Ese es un error del proyecto, no de un programador particular.

En mi experiencia el mayor problema de los programadores es que aunque pasen las pruebas, luego quieren trabajar solos y no quieren seguir instrucciones. Si ya programaron algo, quieren programarlo de nuevo en vez de reutilizarlo. Eso está mal, pero al parecer hay un placer en “volver a sentir lo mismo” que los obliga a escribir lo mismo de otra manera.

¿Cómo detectar eso en una prueba?

Me parece imposible.

Quizás es un problema menor y no importa. Pero por lo menos creo que es un error no contratar definitivamente al desarrollador, porque lo que más necesita la gente es estabilidad, no estar pensando ¿de dónde voy a sacar dinero para comer mañana? Eso los hace estar pensando en otra cosa y siempre el código es el peor en esos casos.


(Esteban) #8

Hola muchachos, se me habían perdido no supe que habían cambiado de plataforma, jeje, no he estado por acá por temas de tiempo pero voy a opinar un par de cositas con respecto a las contrataciones.

Me sumo a todo lo hablado hasta ahora, y quiero recalcar el aspecto de ir mas allá de las contrataciones. Mi opinión es que si bien viene siendo cierto que las entrevistas técnicas son esenciales para el cargo, no es menos importante conocer al postulante a nivel personal, pero no basta con ver el curriculum y sacar conclusiones o pedir referencias, sino conocer su historia, lo que ha vivido en sus empresas anteriores y las enseñanzas que ha sacado a nivel profesional y personal. Lo que sucede en la industria en general es que se ve al curriculum como un papel de antecedentes, un prontuario policial, donde se pre-juzga con cosas muy banales como el tiempo que estuviste en una empresa, ¿por que te fuiste? es una pregunta recurrente que no es nada fácil de responder para el postulante, y el entrevistador no se debe decantar por lo que el piensa que es lo mas “obvio”.

Personalmente puedo contar mi propia historia sobre este asunto: Por temas de la vida estuve sufriendo depresión clínica diagnosticada por casi 2 años, desde mediados del 2013 hasta mediados del 2015, y no me vine a tratar hasta principio del 2015 que fue cuando murió mi padre y la cosa se agravó. A causa de esto empecé a tener problemas en el trabajo como la falta de concentración, problemas de ansiedad, llegaba tarde porque simplemente no sientes motivación alguna, cosas que eran causa de la enfermedad, porque esto es una enfermedad, es como el cancer que tiene que ser tratado con profesionales, no es simplemente una actitud o una forma de ver la vida, el cancer no lo curas simplemente pensando positivo.

Cuando me empecé a tratar con profesionales, por recomendaciones de mi sicóloga decidí parar por 7 o 8 meses para ordenar todo antes de decidir a volver a buscar trabajo y volver a las pistas, esta vez mental y emocionalmente estable, pero sorpresa!, ya no me fue tan fácil encontrar empleo, y las preguntas siempre eran las mismas "¿por qué tantos saltos de empresas en tan poco tiempo? ¿por que estuviste 8 meses sin hacer nada?, y la lista es infinita.

Es obvio el miedo que sienten las empresas y los entrevistadores a este tipo de indicios de inestabilidad, pero si van a haber ese tipo de juicios hay que ver todas las variables y ser abierto de mente. Una persona pasa por lo menos una vez en su vida sobre este tipo de experiencias, y cuando te estabilizas es algo que te cambia la vida para bien, te cambia los valores, tus motivaciones, buscas un sentido a lo que haces día a día lo que hace que hagas mejor tu pega y no solo vas por el sueldo. ¿le sirve eso a la empresa? tal vez, depende de la cultura, de los objetivos en común y de lo que se espera de ti. La recomendación es no tomar a la ligera la entrevista personal, indagar con mente abierta lo mas que se pueda sobre el postulante, si es posible con ayuda de sicólogos.

Sobre el tema técnico, yo quitaría de la ecuación el code review y los unit test. Personalmente he tenido malas experiencias con el code review, específicamente con la herramienta gerrit. Puede servir en la entrevista, pero en el día a día si no se implementa bien puede ser un caos ya que generaría un cuello de botella, sobretodo si el juicio de aprobación pasa solo por una persona, y aplica técnicas nazistas sobre el código de todo el equipo, y eso puede ser contraproducente y puede generar frustración, sobretodo si el perfil a contratar es junior. Los unit test es algo un poco mas delicado, ya que es una buena práctica, pero por lo general no debería ocuparse en una entrevista para medir conocimientos, como comentaron es muy complicado medirlo sobre algo real, y siempre es algo aprendido, es decir, hay mucha parte de la industria que no los ocupa ya que utiliza la técnica de “hechandole pa elante programming”. Si tu organización utiliza unit test como buenas prácticas, lo mas probable es que el postulante tenga que aprender a trabajar así.

Saludos.


(Guillermo Schwarz) #9

Buen tema y buen insight.

Efectivamente si tienes muchos trabajos, te cuestionan, pero también he encontrado lo opuesto, que le preguntan a alguien ¿porqué duraste 10 años en este trabajo? O sea no están conformes nunca.

En realidad lo que hacen es hacer preguntas para no parecer tontos, y no es broma lo que estoy diciendo, son preguntas sacadas de una lista, por eso todos los entrevistadores hacen las mismas preguntas.

Si alguien tiene el manual de cortapalos debajo de la mesa para leerte las preguntas, ¿no corresponde hacer lo mismo con las respuestas?

Si te preguntas porqué te cambiaste tanto, porque aparecieron mejores proyectos.

Si te preguntan porqué duraste tanto, porque el trabajo era estimulante.

Listo, tú haces preguntas tontas, yo te respondo tonteras y quedamos en lo mismo.


(Guillermo Schwarz) #10

" no es menos importante conocer al postulante a nivel personal, pero no basta con ver el curriculum y sacar conclusiones o pedir referencias, sino conocer su historia, lo que ha vivido en sus empresas anteriores y las enseñanzas que ha sacado a nivel profesional y personal"

Lo dudo y en algunos países, como USA, es ilegal. Se supone que contratas a la gente para hacer un trabajo, no para hacerte amigo de ellos. El enfoque es tan equivocado que no sé por dónde empezar a criticarlo.

Si vas a contratar a un programador, ¿sabe programar? ¿Qué más necesitas?

Para que quieres conocer la historia de su trabajo, eso suena mal. Es como si tienes una cita con una chiquilla interesante y te pregunta por tus exs. Mal. Muy mal, Por no decir, pésimo.

¿Quieres saber si llega a la hora? Si terminó el colegio, tenía que llegar a la hora ¿no?

Pero en realidad es problema es otro. ¿El tipo atiende personas en el mesón o se sienta en su escritorio y hace su magia?

Porque he visto muchas empresas que insisten en los horarios y el tipo básicamente llega a la hora, pero está durmiendo con los ojos abiertos, el cerebro sigue dormido.

Creo que antes de decidir qué preguntar en las entrevistas deberías preguntarte qué tipo de profesional quieres contratar y cómo defines el éxito en tu empresa y en tu proyecto. Si tienes claro eso, no debería ser difícil definir pruebas que permitan dilucidar qué debes preguntar.


(Guillermo Schwarz) #11

“Lo que sucede en la industria en general es que se ve al curriculum como un papel de antecedentes, un prontuario policial, donde se pre-juzga con cosas muy banales como el tiempo que estuviste en una empresa,”

JAJAJAJAJA

Así parece.


(Guillermo Schwarz) #12

“Sobre el tema técnico, yo quitaría de la ecuación el code review y los unit test.”

Efectivamente no tiene sentido hacerlo en una entrevista. Sí tiene sentido hacerlo en un proyecto.

Lo importante es que el tipo se peuda expresar verbalmente, qué explique su código.

Escribe una función que dé vuelta un string, en el pizarrón. Luego explícalo. Esto lo explica en mayor detalle http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html


(RIcardo M.) #13

“Si vas a contratar a un programador, ¿sabe programar? ¿Qué más necesitas?”

uff, programar es la parte más fácil… eso lo hace (casi) cualquiera. lo difícil es encontrar personas que puedan resolver problemas, y para eso necesitas más skills entre los cuales por ejemplo está la comunicación, trabajar bien en equipo, la humildad, etc.


(Guillermo Schwarz) #14

“uff, programar es la parte más fácil… eso lo hace (casi) cualquiera. lo difícil es encontrar personas que puedan resolver problemas,”

Veamos, programar puede ser la parte más fácil… para un programador. Pero para alguien que no tenga inteligencia algorítmica, programar es imposible, lo más aburrido y no hay suma de dinero que lo convenza de hacer eso. Aunque alguien que no sabe programar, programar es el infierno.

De hecho no veo la diferencia entre programar y resolver problemas, o al menos, esperaría que un buen programador a nivel consciente sepa lo que es resolver un problema, lo que es un algoritmo, sepa el lenguaje, sepa las mejores prácticas y el código escrito por ese programador refleje eso.

En la práctica el código que leo parece jeroglíficos egipcios, o un largo texto de la edad media sin espacios ni signos de puntuación, que dificilmente se te puede escribir que hace en su conjunto, la cantidad de código repetido no te imaginas que ni un lemming sea capaz de escribirlo.

Y la justificación siempre es “es que estábamos apurados, después lo vamos a corregir” y obviamente dan ganas de ponerle un grillete al susidicho y decirle “no sales de acá hasta que el código no esté bien escrito”.

Es obvio porque lo hacen “quiero mi sueldo, en 2 meses renuncio y otro idiota se queda con el problema”. Todos lo hemos visto, así que no nos saquemos la suerte entre gitanos.

" y para eso necesitas más skills entre los cuales por ejemplo está la comunicación, trabajar bien en equipo, la humildad, etc."

Sí, todo el mundo dice lo mismo. Pero ¿qué comunicación? Si escribo código enredado, si no levanto el nivel de abstracción creando bibliotecas, de qué nivel de abstracción estamos hablando. ¿O estamos hablando de comunicación como en un carrete? Porque ahí los ingenieros estamos en desventaja con respecto a todo el resto de las profesiones, y si hablamos de ingenieros informáticos, el nivel de incomunicación bordea en el de rainman.

¿Qué comunicación necesitamos? Porque en mi experiencia, incluso los ingenieros que emiten 2 sonidos guturales al día, y nada más, se comunican bien cuando se trata de temas técnicos. Si el tipo no entiende de lo que está hablando obviamente se comunica mal, pero ¿no es lo mismo con respecto a alguien que se comunica bien pero no entiende el tema?

Por lo menos los ingenieros tenemos el problema de que cuando alguien no entiende el tema, no le tenemos paciencia. El resto de la gente generalmente tienen mucha paciencia, pero es porque ellos no entienden el tema tampoco, al menos no matemáticamente, para ellos todas las soluciones son factibles, son más bien usuarios del avión que fabricantes del avión. Si vas donde un ingeniero aeronático y le dices “quiero alas cuadradas” probablemente te mande a buena parte, y no es porque el tipo no se sepa comunicar, sino porque está seguro que eso no se puede hacer.

Eso se mal entiende como “el tipo no se sabe comunicar”, porque para alguien ignorante del tema “¿y qué importa?”. Pero para alguien que tiene que asegurarse de que no muera nadie, el tema sí importa.

Junta 2 ingenieros expertos en algún tema y estarán de acuerdo en todos los temas básicos y de complejidad media, pero en los temas avanzados estarán siempre en desacuerdo, por definición de tema avanzado.

Eso obviamente le molesta a las personas que no entienden los temas básicos porque no entienden porqué estan personas son tan airadas respecto a temas que no se sabe realmente de qué están hablando, pero la pelea es apasionada.

Yo no le veo problema a que se discutan esos temas, mientras se mantenga el respeto básico.

Eso de trabajar bien en equipo, ¿a qué se refiere?

No conozco un gerente al que le pidan trabajar bien en equipo. Por definición no es así. Pero en agile y en lean por definición es el equipo quien toma todas las decisiones, es hacerse grande de improviso, no existe otra manera de trabajar que trabajar en equipo. Si es tan por omisión, ¿cómo podría alguien trabajar en un ambiente ágil sin ser un colaborador? ¿O la idea es hacer una pregunta para saber si alguien realmente es un colaborador y pillarlo? ¿Algo así como pásame las llaves de tu auto y de tu casa en la playa y voy a saber si eres realmente un colaborador?

Si se te pide trabajar bien en equipo, te están pidiendo que no molestes a tus compañeros. Pero ¿qué es lo que les molesta? ¿Que tengas una opinión diferente o que les faltes el respeto o que les obedezcas o que todas las decisiones se tomen en equipo?

Porque si es una opinión diferente, diría que quien tiene una opinión diferente tiene derecho a expresarla y justificarla, y hasta que se pruebe su opinión. Por lo menos eso es lo que hago cuando dirijo proyectos: sé que alguien está equivocado y dejo que falle. A veces ellos me demuestran que están en lo correcto. Eso es bueno porque aprendo.


(Javier Chacana) #15

Mi grano:
A mi al menos me interesa saber q potencial tiene el prospecto como para encajar en el equipo. No es fácil tener un genio q no se lleva con nadie y q pone en peligro al equipo completo.

Para próximas selecciones además creo q evaluaré, aparte de fizzbuzz y similares, habilidades de googleo. De verdad me cuesta trabajo aceptar q haya tanta diferencia entre gente q encuentra la solución en 3 min y otros q se llevan días.


(Guillermo Schwarz) #16

Buen punto.

La verdad a mi me pasa lo mismo, y peor que a ti. El tipo hace algo bueno en digamos 2 semanas.

Luego lo único que tiene que hacer es llamar a su solución 500 veces.

No es tan difícil, son 2 líneas de código, gracias a la solución que hizo el mismo…

Y se pone a escribir el código de nuevo… Sin ninguna necesidad ni de negocio, ni tecnologica, ni nada solo por el placer de escribir código enredado.

?porque?

No se, porque se quedan callados como si fueran niños. No hay justificación, excepto crear la posibilidad de más defectos y código repetido, así podemos tener un trabajo infinito sin resultados y con bugs que toma semanas corregir. Y que al corregir tocas tantas líneas que te echas cientos de cosas.

Y esto lo vengo viendo hace muchísimo tiempo.

Si tu dices que le vas a enseñar a googlear… Creo que hasta las viejitas de 60 saben googlear… Creo que el problema es otro, el tipo busca desafíos.

La flojera intelectual es más fuerte que la flojera común. Hay gente que pasa ocupada haciendo lo mismo para nl tener que pensar.

Si alguien se demora días en resolver algo que toma 15 min es que es un débil mental, se está tratando de probar a si mismo que es inteligente en algo que no tiene sentido.

El problema no es no contratar a ese tipo, el problema es que esta tan agotado, que ya no piensa normalmente. Reducir la carga de trabajo, reducir los horarios te puede ayudar. Por ejemplo que trabaje 3 horas diarias y que se vaya a su casa.

En un par de semanas el tipo va a resolver los problemas que al resto les toma horas en un par de minutos.

?como lo se? Porque lo he hecho.