Veo muchas ofertas de trabajo que requieren al menos x años de experiencia. La pregunta es ¿cómo saber cuándo un candidato tiene los años requeridos de experiencia? ¿Qué esperas de una persona con x años de experiencia (editar: efectivamente, ¿cómo verificas si el CV no miente sin depender de la verificación de habilidades)? ¿Qué puede hacer una persona con x años de experiencia que una con y años (con y <x) no puede hacer (editar: suponiendo que tengan habilidades similares)?

Puede haber casos con algún programador apasionado con y años de experiencia que tenga un vasto conocimiento y haya trabajado en múltiples proyectos y otro programador con x años de experiencia (x> y) que haya trabajado en pocos proyectos y no tenga tanta experiencia.

¿Por qué no se puede reducir a algo como esto "si conoces esta tecnología y sabes cómo hacer esas cosas (ya sea diseño, comunicación, estimaciones, etc.) entonces eres apto para nuestro trabajo"?

Sé que no puede contratar a un recién graduado con 1 año de experiencia para el puesto de arquitecto empresarial, pero también veo un problema con los hechos que casi todos los anuncios requieren experiencia. En mi humilde opinión, en primer lugar, debe tenerse en cuenta la pasión.

En primer lugar, no sabía si la pregunta es adecuada para este sitio, pero dado que hay una etiqueta para reclutar y tener experiencia, creo que tiene un lugar aquí.

Su pregunta puede manejarse dividiéndose en dos subpreguntas.

¿Por qué usar años de experiencia como requisito?

Porque es una métrica fácilmente verificable que se correlaciona positivamente con la competencia de programación . La respuesta de Snagulus ya explica los detalles de la correlación, así que me enfocaré en el "por qué".

La dura verdad es que generalmente hay más de un candidato para un puesto determinado. Además, las entrevistas consumen muchos recursos, especialmente si se realizan "correctamente", es decir, las entrevistas técnicas son realizadas por personal técnicamente competente (en este caso, programadores).

Por lo tanto, se debe utilizar algún criterio para examinar inicialmente los CV entrantes , y preferiblemente uno que pueda ser verificado por personal no técnico; en caso de duda, las personas de recursos humanos siempre pueden llamar a empleadores anteriores y verificar que sí, John Smith ha trabajado para X años con ellos.

¿Por qué no utilizar la "pasión" como un requisito en su lugar?

Hay al menos dos problemas con esto:

¿Cómo medir la "pasión"?

¿KLOC registrados? Buena suerte al descubrir que, además, en la programación (y otras disciplinas), más profusa no equivale a "mejor".

¿Proyectos de código abierto / pasatiempo completados? RR.HH. no es fácil de verificar, y muchos programadores competentes tienen razones legítimas para estar inactivos a ese respecto: otras obligaciones que requieren mucho tiempo, largas horas de trabajo con ganas de relajarse, satisfacción profesional simple durante las horas de trabajo, etc.

¿Años de experiencia? Oh espera...

¿Es la "pasión" realmente una buena métrica de competencia?

Como dice Robert Harvey en su comentario, la pasión no es realmente indicativa de una programación competente. En comparación con la experiencia, es una cualidad mayormente ortogonal , es decir, existe:

• programadores apasionados y competentes y
• programadores desapasionados y técnicamente competentes y
• programadores apasionados y técnicamente incompetentes y
• programadores apasionados y no técnicamente incompetentes,
• etcétera etcétera.

El último ejemplo es importante en nuestro contexto: los años de experiencia también muestran que un programador determinado ha logrado funcionar de alguna manera en su trabajo, mientras que un programador apasionado disfuncional podría, por ejemplo, negarse rotundamente a participar incluso en el sistema de gestión de tareas más simple (por ejemplo, Scrum Post-it notes), porque "me ralentiza".

Renuncias finales

En primer lugar, y afortunadamente, los "años de experiencia" a menudo se evalúan "libremente" , es decir, si está solicitando un trabajo con el lenguaje X, pero solo tiene experiencia "comercial" con el lenguaje Y, similar a X, eso también es frecuente. tenido en cuenta.

En segundo lugar, personalmente no soy fanático de "N años de experiencia", y no soy el único. Hay una alternativa simple: especificar "experiencia en" . Por lo general, eso es suficiente como filtro, ya que los candidatos se ven obligados a documentar esa experiencia en sus currículums: si obtiene un candidato para un puesto de programación que anteriormente solo había hecho la espera (¡y esto sucede!), Sabe que algo puede estar mal.

"Años de experiencia" es más una escala de probabilidad que una medida de algo concreto. Con más años, tiene una mayor probabilidad de que una persona haya encontrado cosas como:

• Ha participado en un evento de crisis.
• Ha visto un proyecto de principio a fin.
• Ha visto que un proyecto no puede comenzar o finalizar.
• Ha trabajado en código heredado.
• Ha trabajado en una pizarra en blanco e hizo algo.
• Ha implementado decisiones de diseño.
• Ha diseñado un sistema.
• Ha escrito un error, ha solucionado un problema, ha eliminado un servidor; Se ha jodido, esencialmente.
• Ha arreglado un error.
• Ha encontrado casos extraños en el idioma en el que trabajan y ha visto un lugar donde importan.
• Ha aprendido que las cosas actualmente en la base de código pueden ser tontas.
• Tenga en cuenta que estas cosas son una muestra pequeña, no obligatoria, y también incluyen docenas de pequeñas cosas que se pueden encontrar trabajando en un entorno en vivo.

Una vez más, es algo casual, y depende completamente de / dónde / obtuvieron esos años de experiencia. Una persona podría haber trabajado en un solo proyecto en un equipo de varios cientos de personas y convertirse en altamente especializado. Otro podría haber estado en una pequeña tienda de prueba por fuego y convertirse en un generalista al tratar con servidores / instalación / codificación / QA / DBA / gestión de proyectos. También hay personas que se encuentran obteniendo el mismo año de experiencia una y otra vez.

Es una medida aproximada, pero en promedio una persona habrá estado expuesta a más eventos potenciales de aprendizaje cuanto más tiempo haya estado trabajando, y es útil como un punto de datos preliminar. El resto del currículum (y lo más importante, la entrevista) es para descubrir lo que realmente saben y lo que realmente han hecho.

Contestaré esto abordando cada una de sus preguntas en la publicación.

La pregunta es ¿cómo saber cuándo un candidato tiene los años requeridos de experiencia?

Esto es normalmente lo que el proceso de entrevista pretende filtrar. Se realizan múltiples entrevistas y normalmente puede evaluar la experiencia de un candidato con algunos de sus propios desarrolladores internos.

¿Qué esperas de una persona con x años de experiencia?

Es de esperar que cumplan los requisitos de trabajo que se especifican en un puesto de trabajo. Por ejemplo:

"Estamos buscando un desarrollador PHP senior con más de 10 años de experiencia trabajando en diseño de sistemas y arquitectura para reestructurar nuestras herramientas del sistema como arquitecto jefe, mientras administramos K cantidad de desarrolladores senior y junior y los guiamos en el camino. El trabajo también requiere ... (etc. etc.) "

¿Qué puede hacer una persona con x años de experiencia que una con y años (con y <x) no puede hacer?

Estás viendo la experiencia incorrecta en este caso. Los puestos de trabajo no solo requieren varios años, sino también experiencia en las tecnologías que utiliza la empresa. Como si pudieras tener 10 años de experiencia en el desarrollo de C ++, y digamos que soy una empresa de juegos que busca desarrolladores de C ++ con incluso 5 años de experiencia. Aún no serías mi candidato ideal porque nunca antes habías trabajado en la industria del juego. Mi puesto de trabajo en realidad especificaría: X años de experiencia en los aspectos A, B, C de la programación.

Puede haber casos con algún programador apasionado con y años de experiencia que tenga un vasto conocimiento y haya trabajado en múltiples proyectos y otro programador con x años de experiencia (x> y) que haya trabajado en pocos proyectos y no tenga tanta experiencia.

Lee mi respuesta anterior. La experiencia está ligada a las herramientas en las que tiene experiencia. X cantidad de años en herramientas A, B, C.

¿Por qué no se puede resumir a algo como esto "si conoces esta tecnología y sabes cómo hacer esas cosas (ya sea diseño, comunicación, estimaciones, etc.) entonces eres apto para nuestro trabajo"?

Esto puede y sucede. Si puedes demostrar tu valía, la experiencia en años no importa. Para un tipo como usted, parece más adecuado para una tienda de desarrollo más pequeña, donde el entrevistador / reclutador es un desarrollador en sí mismo. Las empresas más grandes normalmente tienen RR.HH. haciendo este tipo de cosas, por lo que hacen que los requisitos de trabajo sean tan amplios que, básicamente, se necesita un doctorado con más de 15 años de experiencia para escribir pequeñas funciones para su sitio web (exageración excesiva, pero explica los defectos en la contratación de programadores, especialmente para las empresas más grandes, aunque no todas sufren de esta dolencia)

Años de experiencia es simplemente un filtro que proporciona una estimación "aproximada" de lo que se espera de la persona que utiliza las habilidades deseadas que figuran en la descripción del trabajo.

Esto es bastante lo que esperaría, pero otros pueden tener ideas diferentes:

2 años o menos: debe poder realizar tareas específicas que le indiquen, y los empleadores deben saber que habrá una curva de aprendizaje con una buena cantidad de supervisión para la mayoría de esas tareas.

De 3 a 5 años: debe ser capaz de realizar las tareas que se le indican que haga, sin demasiadas manos porque ya debería haber realizado tareas similares en su experiencia de 0 a 2 años. También debería comenzar a mostrar alguna iniciativa "inteligente" y ser capaz de manejar tareas más pequeñas que no están necesariamente claramente definidas. (p. ej., puede diseñar módulos a partir de los requisitos, donde debe rastrear algunos de esos requisitos usted mismo).

5 - 7 años - Debería poder trabajar por su cuenta y decidir cuáles son esas "tareas" desde arriba. Debería poder manejar tareas de tamaño medio que no están claramente definidas. (por ejemplo, ser capaz de diseñar / implementar / vender subsistemas). También debería comenzar a liderar equipos de subsistemas en este rango de tiempo. Haga las presentaciones necesarias de los subsistemas de los que son responsables, al menos al equipo interno.

8 - 10 años - Se puede confiar en que se les dará los subsistemas críticos y / o muy grandes del proyecto. Experto residente en varias tecnologías. Puede liderar grandes equipos de subsistemas. Haga presentaciones de los subsistemas de los que son responsables ante el cliente.

Más de 10 años: puede manejar prácticamente cualquier tarea de software que se les presente, dentro de los límites de la descripción del trabajo Y la mayoría de las otras tareas de software semi-relacionadas. Experto residente en una gran cantidad de áreas de software. Puede liderar grandes proyectos, desde los requisitos hasta la liquidación. Comprende el diseño del sistema y no solo el diseño del módulo / subsistema. Es capaz de diseñar sistemas confiables, robustos y mantenibles. Es la interfaz de software para el cliente, incluidas las presentaciones desde una perspectiva de sistemas. Puede armar adecuadamente propuestas de ofertas y horarios.

Si bien la definición de años de experiencia es vaga, no es solo para beneficio del empleador, sino que también es una guía para quienes buscan trabajo. Por lo tanto, si lo contratan, alegando que tiene 8 a 10 años de experiencia y que viene al trabajo y necesita que le digan cada pequeña tarea que debe hacer, en el mejor de los casos su futuro en la empresa es "muy limitado" si incluso dura mucho mucho tiempo en absoluto. Las primeras impresiones son difíciles de cambiar, por lo que incluso si mejora como desarrollador, es probable que las personas mantengan su impresión original de usted.

He visto a un buen número de desarrolladores "senior" contratados que desaparecieron en cuestión de meses o en un par de años y se incorporaron al programa de "desarrollo de empleados", que es realmente la vía rápida para ser el primero en la lista de despidos. Si esos mismos desarrolladores hubieran llegado a un nivel más bajo (por supuesto, eso significa un sueldo más bajo), entonces muy bien podrían haber sido considerados una contratación exitosa y visto como un rendimiento adecuado.