Cómo contratar mejores desarrolladores

[Nota] Este es un artículo escrito desde la perspectiva de una empresa de contratación o desde la perspectiva de un empleado que quisiera tener colegas agradables y competentes.

Voy a señalar aspectos relacionados con los desarrolladores en su conjunto, pero hablaré más de la experiencia de un desarrollador JS fullstack, por lo que algunas cosas podrían no encajar como un guante para su caso.

Señalando estas cosas, no se trata solo de lo que está mal en la mayoría de los procesos de contratación, sino también de algunos indicadores clave sobre qué mirar y qué podría mejorarse (hacer y no hacer, pero en su mayoría no).

  1. No hagas preguntas estúpidas

Preguntarle a alguien cuántas piñas caben dentro del cadáver de una ballena solo para ver si encaja con el resultado de sus ingeniosas respuestas de "magia" no ayudará a nadie, especialmente al cerebro del desarrollador.

2. Evite ejercer presión y / o establecer tareas que requieren mucho tiempo o que son demasiado complicadas

A menos que su empresa sea realmente c ** p, lo más probable es que no sea necesario lanzar una función en 20 minutos, y estoy bastante seguro de que no implicará retrocesos o árboles binarios, ni optimizaciones O (n) con hashmaps.

Obtener una respuesta de ese tipo de preguntas u otras también depende de la disposición mental y el estado de ánimo del desarrollador en ese momento específico, y realmente no te dice demasiado.

Todavía vale la pena hacerlo si las pruebas son realmente simples y solo se utilizan para filtrar las realmente malas, o simplemente para que usted mire el proceso de pensamiento y comience una discusión sobre las compensaciones.

3. Escribir código en papel (especialmente código específico del idioma)

A menos que sea google, esto suele ser molesto AF. El hecho de que las grandes empresas lo hagan no significa que sea bueno, solo significa que pueden permitirse el lujo de ser un despilfarro porque la gente seguirá viniendo de todos modos, por lo que solo tienen el lujo de conseguir personas con una base teórica muy sólida, incluso si usan conocimiento o no.

Seamos honestos aquí, olvidas la mayoría de los algoritmos en 2 a 3 años después de salir de la universidad, a menos que estés trabajando en un producto de muy bajo nivel.

Pero ... ¿un buen desarrollador necesita saber cómo hacer 4 tipos de clasificación? Lo dudo.

Lo que realmente cuenta es poder entenderlo solo leyéndolo y poder descubrir las diferencias y particularidades en cada uno.

Entonces, tal vez solo haga eso clasificándose y pregúntele qué hace, desafíelo a que lo explique en términos más simples para detectar una buena comprensión del código. Además, si puede detectar las habilidades mentales necesarias para traducir esa imagen en algo similar, eso tiene más sentido para una persona menos técnica, sería genial.

Porque si hace todo eso, entonces puedes estar bastante seguro de que podría revisar cada uno de esos sofisticados algoritmos de gráficos que tanto amas en pocos días y volver a aprender todo si realmente lo necesitas.

4. Deje de hacer preguntas de API con respecto a una pieza de tecnología / lenguaje que no se trata de eso. Busque conceptos en su lugar

Lo que quiero decir con esto es que preguntarle a alguien cuánto del lenguaje / sintaxis de consulta para una operación MongoDB no tiene ningún interés ... creo que las personas que recuerdan perfectamente la sintaxis API de memoria son generalmente desarrolladores peores que las personas que lo olvidan.

En serio, ¿de qué otra manera aprenderás algo nuevo y rápido si memorizas cosas como en la escuela primaria? En el mundo real, tendrá que aprender otra tecnología mañana para mantener la ventaja.

¿Dónde está tu poder ahora?

Al buscar conceptos me refiero a que debería ver, por ejemplo, si comprende conceptos como transaccionalidad, escalabilidad, tipos de coherencia, facilidad de integración y facilidad de uso de las API disponibles para su motor, diferentes tipos de bases de datos (documento, sql , gráfico, etc.) y también para qué se debe usar, casos de uso típicos y puntos débiles / puntos fuertes en general.

Recordar la API de SQL es otro ejemplo, "¿cómo se hace este JOIN o esta y aquella operación?". No necesita recordar eso por el resto de su vida, si tiene la idea básica de las bases de datos relacionales, un buen desarrollador debería poder decirle las diferentes mutaciones de estado y la forma en que se realizan las operaciones en este tipo de bases de datos, compensaciones que vienen con ellos.

Y todo eso con un uso de API menor o nulo.

Un buen desarrollador no es un desarrollador que sepa cómo resolver su problema en un documento, es uno que sabe cuáles son las operaciones permitidas y las abstracciones que se pueden hacer para resolverlo en un entorno específico, y no necesariamente tiene una pantalla de matriz dentro de su cabeza con instrucciones o fragmentos de documentación API.

Por ejemplo, pregúntele qué tipo de base de datos debe usar para uno de sus sistemas que realiza una tarea / problema específico de dominio que encontró en sus proyectos, y deje que le diga el razonamiento detrás de él.

5. Sí, pero ¿conoces realmente este marco? ¿Cuánta experiencia tienes con eso?

A veces importa, a veces no. Preguntar qué tipo de experiencia tiene con React (hablando de Core React no toda la colección de trozos de biblioteca de Game of Thrones) es básicamente no preguntar nada si ha pasado más de 2 años codificando en JS hasta ese momento.

Reaccionar en sí mismo es una lectura de 2-3 días como máximo para hacer un uso práctico de la misma, ¿es este tiempo "perdido" crítico para su empresa? Bueno, si es así, tal vez sea una empresa basura de todos modos, así que no te molestes en cambiar eso ... por favor, sigue adelante y luego vete (:

Si no es así, puede preguntarle al desarrollador cosas como cuánto tiempo pasó para aprender (inserte su nombre) marco, obtener más información sobre el proceso de pensamiento, las opiniones y el cambio progresivo en ellos (pasos y curvas de aprendizaje , obstáculos, etc.), y después de eso compare estos datos con otros en el equipo.

Waay más útil. Pregúntele qué le gusta de eso y qué no, esto debería darle una idea rápida y buena de la cantidad de profundidad que tiene en ellos si realmente está interesado (por alguna razón)

6. Un buen desarrollador debe saber buscar cosas

Creo que esta es la parte que marca la diferencia entre un nuevo graduado / junior y un desarrollador de nivel medio o senior.

La capacidad de encontrar respuestas por sí mismo, buscar más información, leer documentación y buscar otros puntos de vista.

Los malos desarrolladores generalmente intentan reinventar la rueda cuando no es el caso. Intenta buscar ese rasgo, y si falta, definitivamente es un no-no.

7. ¿Dónde te ves dentro de X años?

Si él responde a esta búsqueda ... es broma ... solo por favor no, esta pregunta merece una sección propia porque hace que las otras preguntas estúpidas se vean bien.

8. Obtenga una mejor visión de sus habilidades técnicas al hacer que sea divertido para todos

En realidad es bastante simple, darle una tarea de complejidad baja / media y dejarle construir esa solución. Haga que haga un seguimiento de su tiempo transcurrido aproximado que se utilizó en cada bloque principal de la funcionalidad que le interesa, y tal vez haga una pregunta aquí y allá después de que haya terminado.

A la gente le gusta que la desafíen, y hay un montón de información que puedes obtener sobre alguien al hacerlo, en lugar de presionarlo para que haga cosas como la prueba de pizarra.

Además, ahora puede ver qué tan rápido puede comprender "insertar su nombre de marco".

9. No tome en cuenta sus opiniones sobre sí mismo

¿Eh?

Preguntarle a un desarrollador de rockstar (opcionalmente baja autoestima) sobre sus habilidades y compararlo con las respuestas de un desarrollador de nivel medio no le dirá nada sobre esas habilidades que busca, solo le dirá a lo sumo algo sobre rasgos personales.

Cuanto más aprendes, más te das cuenta de que no sabes mucho, es por eso que el Síndrome Impostor es algo real que está sucediendo en este momento, especialmente en el mundo JS.

Si su objetivo es obtener información técnica útil de este tipo de preguntas, ya debería descartarlas.

10. Dar suficiente tiempo para probarse

El mundo de la tecnología es complicado, y las curvas de aprendizaje son empinadas incluso para los más brillantes, la única mejor manera de saber con certeza si alguien encaja es pasar varios meses de trabajo con esa persona, es decir, si puede permitírselo.

Todos los demás indicadores no dicen mucho en comparación con este, ni siquiera la experiencia. Tenga esto en cuenta porque cualquiera que sea su plan de averiguar un desarrollador desde todos los ángulos, lo más probable es que falle para muchos candidatos potencialmente buenos y tenga éxito al menos para algunos malos.

___________________________________________________________________

Gracias por leer :).

Intenté intencionalmente evitar escribir pronombres específicos de género (él / ella) porque es 2016 y quiero evitar ofender a las personas asexuales y a algunas especies de caballitos de mar. Amo los caballitos de mar.