He visto dos tipos de entrevistas y ambas son horribles.
Estilo 1: Google, Facebook y cualquier otra startup “genial”
Serie de desafíos de codificación ficticia de Cracking the Coding Interview (libro de 2011). Asegura que esta persona realmente leyó el libro y se preparó. Tiene aproximadamente un 5% de relevancia para el trabajo real en Google o Facebook y exactamente un 0% de relevancia en cualquier otro lugar. Principalmente equivale a novatadas hacia los ingenieros, que realmente hacen el trabajo real y no tienen tiempo para memorizar las respuestas a preguntas como: “Cómo verificar si el árbol binario está equilibrado …”
- Desarrolladores de software: ¿Puede describir su primer trabajo en términos de su productividad en comparación con ahora?
- ¿Qué habilidades como desarrollador deberías conocer para conseguir un trabajo en el mercado?
- ¿Qué habilidades / idiomas debo aprender para convertirme en desarrollador de software o arquitecto de software?
- ¿Cómo es trabajar en Pagalguy como desarrollador de software?
- ¿Los desarrolladores de Windows también usan Linux?
Estilo 2: empresas tecnológicas no tecnológicas o no geniales
¿Conoces la tecnología X? Explica en detalle cómo funciona. Peor aún, la explicación debe coincidir con la visión equivocada del entrevistador.
Este tipo de preguntas es básicamente disparar en la oscuridad. Es posible que tenga un gran tipo, que no tuvo la oportunidad de trabajar con la tecnología específica, pero será capaz de resolver el problema y retomar la tecnología en aproximadamente un mes. Es posible que tenga un chico, que recientemente vio la charla de YouTube sobre esta tecnología específica y lo recitó perfectamente. Eso no significa que podrá entregar cualquier cosa.
La forma correcta de entrevistar es evaluar las habilidades de resolución de problemas y el compromiso del solicitante. Por lo general, pido que describa el proyecto más emocionante entregado por el solicitante.
Durante la discusión, quiero hacer que el solicitante comprenda muy bien el problema comercial que se está resolviendo. Quiero escuchar una explicación muy detallada de la solución. Si se menciona que cierta tecnología se usa ampliamente, entramos en detalles sobre cómo se seleccionó, cómo se usó y cómo funcionó. Quiero escuchar los SLA del sistema y cómo se cumplieron. Quiero escuchar cómo el solicitante trabajó con el equipo y cómo su parte interactuó con los otros componentes.
Sorprendentemente, muy pocas personas pueden pasar esta prueba. Muchas personas están demasiado concentradas en (1) y (2) arriba y no prestan atención a lo que es importante o no traen a la luz los detalles correctos.
El siguiente desafío es la tarea, que es relevante para el trabajo. Por lo general, requiere cierta comprensión de los algoritmos. Esto no se hace en pizarra. El código de trabajo real debe ser entregado. Me permite evaluar no solo la parte funcional, sino también la calidad del código.
Nuevamente, pocos pasan esta prueba. A menudo, el código es difícil de seguir, faltan pruebas unitarias o la solución no es óptima desde la perspectiva del rendimiento. Si el código se ve bien, limpio y lo suficientemente simple, al resolver el problema, lo revisaremos y nos aseguraremos de que el solicitante realmente lo haya escrito. Podríamos pedir modificar el código para expandir un poco la funcionalidad.