Últimamente, se han publicado tantas historias sobre malas entrevistas en el centro que a veces surgen dudas, y ¿hay buenas entrevistas en la naturaleza? Entonces, por el bien de la diversidad, consideraremos un ejemplo de un buen enfoque *. La historia irá desde el punto de vista del desarrollador del empleador, que está directamente involucrado en el proceso de contratación.
* probablemente
Disposición
Un pequeño equipo de producto (30-40 personas) dentro de una gran empresa (varios miles de personas). El equipo incluye a todos los involucrados en el proyecto: desarrolladores completos y front-end, diseñadores y front-endólogos, probadores, especialistas en relaciones públicas, analistas, autores de textos, etc. En general, tratamos de externalizar el trabajo menos especializado a otros proyectos, y el desarrollo móvil no es una excepción.
Tenemos una aplicación móvil multiplataforma escrita en Xamarin Native para iOS y Android. Al mismo tiempo, estamos completamente listos para llevar lo mejor del desarrollador experimentado que escribió solo para una plataforma, siempre que esté listo para estudiar el desarrollo de un segundo sistema operativo.
Etapa 0: conocí dos soledades
O el desarrollador se topa con una vacante y envía un currículum, después de lo cual HR le envía algunas preguntas aclaratorias, o HR tropieza con un currículum del desarrollador, después de lo cual envía la misma serie de preguntas.
Estas preguntas son el filtro mínimo para la adecuación; no habrá problemas técnicos. Además, el empleador ya transmite el currículum y las respuestas al desarrollador, y él decide si ir más allá o no. Durante el mes pasado, miré un par de docenas de currículums, y no tengo idea de lo que el candidato debe escribir y responder, por lo que tuve que decir que no en esta etapa. ¿Escribir a la vacante del desarrollador de Android "escribo solo para iOS, porque Android apesta"?
Etapa 1: tarea de prueba o código de muestra
La tarea de prueba se da sin límites de tiempo, aunque en la práctica no debería tomar más de una noche. Como parte de la aplicación de prueba será:
- tres pantallas: dos listas enlazadas + formulario de entrada de datos, que, si se desea, se puede reemplazar con una ventana modal
- trabajo en red
- trabajar con el almacén de datos (la tarea implica una base de datos, si el desarrollador puede justificar otra conclusión, somos bienvenidos)
Sin embargo, no todos los desarrolladores están listos para escribir una prueba, por lo que inmediatamente ofrecemos una alternativa: enviar el código de alguna aplicación preparada, donde habrá el mismo conjunto (red, base de datos, navegación en pantallas, entrada del usuario). Bueno, hay otras opciones posibles:
- la aplicación es demasiado pequeña, el código no es indicativo o causa demasiadas preguntas, por favor haga nuestra prueba
- la aplicación es adecuada, pero hay algunos matices; realice pequeñas mejoras (menos que por la noche)
Con base en los resultados de la prueba, llamamos al desarrollador para una entrevista o rechazamos, pero en el segundo caso se dará una revisión detallada: qué se hace bien, qué es discutible, qué preguntas surgen, qué vale la pena leer, etc. Como resultado, todos ganan:
- el candidato recibe un código, que luego puede reutilizarse en otra entrevista con principios similares, así como comentarios para trabajar en usted mismo. Funciona Bueno, al menos nos enviaron tareas de prueba escritas originalmente para otras compañías, por lo que parece funcionar;
- El empleador ahorra tiempo en cuestionarios y otras cosas. ¡Y qué contento es que el entrevistador sea introvertido, que no necesita realizar 1-2 entrevistas por semana, si lo supiera!
Etapa 2 - Entrevista
En la entrevista, ciertamente no solo se hablará sobre la vida y sobre el lugar de trabajo anterior, sino también preguntas sobre la tarea de prueba. En esta etapa, es bastante simple entender si una persona escribió una prueba, si comprende lo que está escrito allí, si puede justificar una u otra solución, cuáles son sus horizontes, etc. Las preguntas no se hacen en el aire, sino con la capacidad de tomar el teclado y meter este mismo código. A veces le pedimos que reescriba algo un poco sobre la marcha o que lo corrija, le hacemos preguntas en el formulario "pero si todavía existiera tal requisito ..."
A continuación habrá 1-2 pequeñas tareas prácticas, que dependen de la tarea de prueba. Nuevamente, le damos el teclado en la mano (¡conectado a una computadora, una computadora con monitor!) Y le pedimos que escriba o edite algo. Una de mis cosas favoritas es dar una función funcional pero mal escrita para 10-20 líneas y sugerir refactorizarla. Inmediatamente queda claro si el candidato tiene un código incorrecto, qué sabe sobre las construcciones del lenguaje, si puede leer el código de otra persona más en la lista.
Y eso es básicamente todo. En un máximo de un par de días le daremos una respuesta al candidato. Sin embargo, la mayoría de las veces la respuesta se da el mismo día). Y en caso de falla, nuevamente habrá una justificación adecuada. Bueno, si no es suficiente, el candidato siempre puede pedirles a los desarrolladores contactos de la entrevista para aclarar algunos puntos, y lo más probable es que se los den.
Pero el candidato podría haber engañado
De verdad. Incluso podría
enviar un gemelo . Bueno, puede que no haya sido engañoso, simplemente cometimos un error en la entrevista. En tal caso, hay una cosa maravillosa llamada "período de prueba". Además, trabajar en una gran empresa (al menos en nuestro caso): no completar un período de prueba no significa una separación del cien por ciento de la empresa. Al final, el desarrollador podría ser bastante bueno, pero no echó raíces en un equipo en particular; en este caso, siempre hay proyectos alternativos.
¡Así que para! Reconocí al equipo en cuestión, la entrevisté hace un par de años y allí el esquema era muy diferente.
Sí, me arrepiento, luego pequé con pequeñas encuestas y entrevistas sin una prueba. Pasó mucho tiempo, tanto el suyo como el de otra persona. Entonces, cuando se trataba de nuevas búsquedas para el desarrollador, decidí probar un enfoque diferente. ¿Los desarrolladores escriben código? Genial Muéstrame tu código y te diré si debemos ser entrevistados.
¡Pero lo descubrí en la empresa! Se instaló en otro proyecto, y allí también, ¡todo está mal!
Y aquí está la situación con la astucia. Un flujo decente de desarrolladores de back-end / full-stack va a nuestra compañía, y hay varios cientos de tales desarrolladores en la compañía. Por lo tanto, el proceso de reclutamiento ya se ha establecido y estandarizado de manera justa. Mientras tanto, hay pocos desarrolladores de dispositivos móviles en la empresa, por lo que es más fácil para nosotros experimentar con enfoques de entrevista.
¡El enfoque descrito tiene otras desventajas!
Esperando por ti en los comentarios. Discutimos ;-)