Si la experiencia es un factor para medir la futuraproductividad de la gente de sistemas o no, si un Senior puede tener 2 años de experiencia en una tecnología X y seguir siendo senior... Muchas opiniones encontradas.
En este mismo blog publiqué "Demasiado Jr para Jr " y "Trainee "
Los invito a leer esta publicación sobre el "mito" de los años de experiencia. Un estracto
Realmente coincido en que hay ciertas "medidas" que se toman cuando un entrevistador debe decidir si una persona es coincidente o no con lo que su cliente ( interno o externo) le pide para cubrir un puesto. Tiene frente a sus ojos un requerimiento de un "Senior con mas de 4 años de experiencia" y el CV de un candidato, con 3 años de experiencia en la herramienta mandatoria, pero un background tecnológico de proyectos calificable como "senior"This toxic, counterproductive years of experience myth has permeated the software industry for as long as I can remember. Imagine how
many brilliant software engineers companies are missing out on because they are completely obsessed with finding people who match-- exactly and to the letter-- some highly specific laundry list of skills.
Somehow, they've forgetten that what software developers do best is learn. Employers should be loooking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language -- and serving them up interesting projects they can engage with.It's been shown time and time again that there is no correlation between years of experience and skill in programming. After about six to twelve months working in any particular technology stack, you either get it or you don't. No matter how many years of "experience" another programmer has under their belt, there's about even odds that they have no idea what they're doing. This is why working programmers quickly learn to view their peers with a degree of world-weary skepticism. Perhaps it's the only rational response when the disconnect between experience and skill is so pervasive in the field of software
engineering.
I'm not saying experience doesn't matter in software development. It does. But consider the entire range of a developer's experience, and realize that time invested does not automatically equal skill. Otherwise, you may be rejecting superb software engineers simply because they lack "(n) years of experience" in your narrow little technological niche-- and that's a damn shame.
Las "medidas" y la evaluación de adecuación de un selector ( por mas experimentado en IT que sea) y una persona "de sistemas" serán diferentes frente a la misma posición. Lo excelente es tomar el trabajo de aunar criterios, de generar un proceso que saque afuera los mitos ( hay varios, no solo este.. el de los años de experiencia como parámetro) y logre sacar el mejor jugo de la presentación y posterior incorporación del candidato.
7 comentarios:
Totalmente de acuerdo, en mi caso tengo un monton de años de experiencia en desarrollo y por necesidades del proyecto me converti tambien en un experto en inversiones.
Cada laburo, bueno o malo te deja una experiencia, la sabiduria de cada uno esta en no descartar nada.
Al fin y al cabo, la derrota es la mejor maestra de todas.
Creo que la capacidad, la voluntad y las posibilidades de desarrollarse independientemente son factores fundamentales.
Eso un reclutador lo puede detectar si sabe que busca.
Totalmente de acuerdo, se de casos de gente que con más de 6 años de experiencia sigue siendo semi-senior, y también conozco gente que con 3 o 4 años de experiencia se desempeña como el mejor de los seniors.
Me parece que ésta manera de pensar está generando problemas en las empresas, ya que suelen poblarse con recursos que no siempre son lo esperado.
He asistido a muchas entrevistas (admito que muchas veces fuí solo con la idea de "tantear" el mercado) y la verdad es que en muchas ocaciones, tuve que dirigir la entrevista yo, porque el entrevistador parecía no saber que preguntar y solo se basaba en repasar mi CV de una punta a otra.
Creo que en una época en que los recusos faltan, y las empresas se pelean por contratar "talentos" deberíamos re plantear cómo se realizan los procesos de selección, y cómo se ejecutan los mecanismos de retención, que es otro problema recurrente.
Martinc, Damian: gracias a ambos por los comentarios
Todos coincidimos en la necesidad de cambiar, lo que pasa es que es "lugar còmodo" el solo medir ese indicador y de la manera en que hoy se hace
Saludos,
Coincido, y lo que creo que da la seniority de una persona es tambien la "actitud". El conocimiento se puede adquirir en cualquier momento y por infinidad de canales, no asi la forma de desenvolverse. Por fin leo en algun lado algo que vengo pensando de hace años. Y me parece que la unica forma que encuentro de verlo plasmado al 100% es empezando mi propio proyecto de laburo. Alguien me presta $50.000 como para arrancar? ;)
De cualquier manera, la demanda del mercado (veremos que nos depara el 2009) provoca que muchas veces se contrate gente sabiendo que no corresponde a la categoría ofrecida, pero que tiene "potencial" para alcanzar y desempeñarse en dichas funciones en el corto plazo. Pero claro, no creo que con una entrevista de 15 minutos baste para determinar el potencial real de alguien.
Es asi como me encuentro con desarrolladores que te dicen "a mi me tomaron como semi-senior, pero yo aclare que no tenia experiencia...", team leaders con un año de experiencia en programación (esta bien, estamos discutiendo el tema de los años de experiencia, pero tampoco vayamos a los extremos!), Managers que no saben algunas cuestiones elementales o que no terminan de diferenciar los roles entre un Project Leader y Project Manager (eso si, cursando su MBA) y seguramente la lista sigue en escalas superiores...
Igual, ojo...yo también hago mea culpa y he tomado a cualquiera cuando la condición era "tiene que entrar gente, si o si" porque sino se cae el proyecto, pero sin dudas que es patear el problema para adelante.
De cualquier manera prefiero esta situación actual a la pre 2001 ;)
solo agregar que pienso que "años de experiencia" no guarda relación directa con la profundidad alcanzada en el conocimiento de una determinada tecnología y/o herramienta...
y más aún, diría que las partes más complejas de la mayoría de los desarrollos se suelen efectuar en cortos, intensos y excitantes períodos, siendo el resto del desarrollo algo así como un "simple" decorado :)
Tal cual como dijeron varios antes, los años de experiencia en sí aportan poco sin considerar qué experiencias fueron y en qué contexto se tuvieron.
Igualmente crítica es la cuestión del aprendizaje, justamente trabajo con un profesional de un décadas de experiencia que ya ha pasado por 2 ciclos de renovación/actualización de conocimientos, habiendo trabajado al más alto nivel y ahora se está capacitando, ya en su 3er. ciclo, como adm. de redes. Habiendo comenzado como trainee desde cero, pocos meses después ya está en un nivel Junior sólido y avanzando firme...
Para los que recién empiezan recomiendo. si se puede, elegir con atención sus primeros puestos, así más tarde van a tener una perspectiva profesional y técnica mucho más completa que al simplemente elegir "hacer algo para ganar experiencia".
Publicar un comentario