He practicado más de 300 preguntas de algoritmos en LintCode y LeetCode. He estado desempleado durante casi 9 meses y obtuve 8 entrevistas y todas fallaron en la prueba de codificación. Todavía no puedo recibir ninguna oferta. ¿Qué tengo que hacer?

Tuve que reírme fuerte con la primera oración de Jon Peterson. Es tan cierto. La siguiente es una historia real del mismo tema.

En 1986 conseguí que mi primer interno fuera mentor, un tipo que luego se convirtió en millonario de Microsoft, y cuya riqueza puede ser mía por lo menos en un orden de magnitud. Hace treinta años era un novato fuera de la universidad.

Hubo algún problema que necesitábamos resolver y él se acercó a mí sobre qué tipo de algoritmo de clasificación usar. Su conocimiento de la teoría de la clasificación era impresionante, y había ido a una buena escuela. Le dije: “Usa el que se llama SORT en la biblioteca de Boeing Fortran”.

Mi interno estaba aturdido, incluso desinflado. Estaba completamente seguro de que implementaría rutinas de clasificación optimizadas cada día de su empleo, y como yo, probablemente nunca se le pidió que lo hiciera.

Si bien conocer los entresijos de los diversos algoritmos lo convertirá en un mejor programador, los mejores y mejores programadores se emplean para tomar decisiones sobre cómo unir a 45 miembros bien elegidos de los 300 algoritmos que ha estudiado y hacerlo de manera coherente manera que otras personas puedan entender.

Me entrevisté y fui entrevistado varias veces, y descubrí que la mayoría de las veces las personas (incluido yo mismo) rechazamos una entrevista debido a las siguientes razones:

1. No encontrar una solución a un problema:
   Si no puede encontrar una sola solución para un problema, entonces definitivamente es una señal de alerta, ya que eso se refleja mal en sus habilidades para resolver problemas. Además, no tenga miedo de proporcionar una solución no óptima inicialmente. Una solución no óptima es mejor que ninguna solución.
2. Proponiendo soluciones pero no puedo implementarlas:
   Eso significa que necesita trabajar más en sus habilidades de implementación. Escriba montones y montones de código y asegúrese de utilizar una pizarra o lápiz y papel para imitar la experiencia de la entrevista tanto como sea posible. En una entrevista, no tendrá un IDE con autocompletado y resaltado de sintaxis para ayudarlo. También asegúrese de estar muy cómodo con el lenguaje de programación que elija.
3. Resolviendo el problema pero no de manera óptima:
   Eso podría significar que se está perdiendo un conocimiento fundamental de las estructuras de datos y algoritmos, así que asegúrese de conocer bien sus conceptos básicos.
4. Resolviendo el problema pero después de mucho tiempo, o después de recibir demasiadas pistas:
   Nuevamente, necesita más práctica para resolver problemas.
5. Resolviendo el problema pero con muchos errores:
   Debe probar su código correctamente después de escribirlo. No espere a que el entrevistador le señale los errores. No querrás contratar a alguien que no pruebe su código, ¿verdad?
6. No hacer suficientes preguntas al entrevistador antes de sumergirse en el código:
   Zambullirse directamente en el código sin hacerle suficientes preguntas al entrevistador es definitivamente una señal de alerta, incluso si se le ocurrió una buena solución. Le dice al entrevistador que eres arrogante o que eres imprudente. Tampoco está a su favor, porque puede terminar resolviendo el problema incorrecto. Discutir el problema y hacer preguntas al entrevistador es importante porque garantiza que ambos estén en la misma página. Las respuestas del entrevistador a sus preguntas también pueden proporcionar algunos consejos muy útiles que pueden simplificar enormemente el problema.
7. Ser arrogante
   Si te perciben como arrogante, nadie querrá contratarte sin importar cuán bueno seas.
8. Mentir en el currículum:
   Afirmar falsamente el conocimiento de algo o mentir sobre el historial laboral es una gran señal de alerta. Muestra deshonestidad, y nadie quiere trabajar con alguien que es deshonesto.

Espero que esto ayude, y buena suerte con tus futuras entrevistas.

Hay varias cosas que debe hacer antes de programar otra entrevista:

1. simule una entrevista en leetcode y grabe usted mismo. Luego mire su grabación y anote las cosas que nota que son desagradables o que necesitan mejorar.
2. pídale a un amigo que le haga una pregunta de comportamiento y pídale sus comentarios honestos sobre lo que le falta o puede mejorar.
3. Si tiene un amigo que se entrevista activamente, pídales que se burlen de usted y le den su opinión.
4. intente una sesión de entrevista técnica profesional simulada y pídales que lo evalúen tanto en cuestiones de comportamiento como técnicas.

Tome todas las notas, practique cómo abordarlas una por una y haga lo anterior nuevamente para medir su mejora.

Con la práctica guiada, definitivamente mejorarás.

Algo más.

Si estuviera contratando a un desarrollador de nivel medio, buscando quizás una experiencia comercial de 5 a 8 años, el tipo de desafíos en esos sitios web representaría aproximadamente el 25% del total de puntos de entrevista. Supongo que después de tanta práctica eres realmente bueno para resolver ese tipo de problema. Así que ahora necesitas mirar otras áreas.

Las otras cosas que me importan, en equilibrios muy generales, son:

1. 25% ¿Pueden resolver problemas del mundo real de manera creativa? Los algoritmos pueden ser tanto del mundo real como creativos, pero generalmente no lo son. Son de nivel de código, y las soluciones en el mundo real son casi siempre de nivel superior. Supongamos que tiene el desafío de determinar cuándo un usuario ha compartido la contraseña de un sitio web con su amigo, rompiendo así los Ts y C del sitio. Eso implica preguntas como:

1. ¿Cómo distinguimos entre alguien con dos computadoras portátiles y alguien que ha compartido su contraseña?
2. ¿Son los falsos positivos mejores o peores que los falsos negativos desde el punto de vista comercial?
3. ¿Cuánta complejidad adicional agregará esto a mi aplicación? ¿Debería retrasarme diciendo que este problema no vale la pena?
4. ¿Se puede resolver todo el problema mediante el análisis de archivos de registro sin código de aplicación adicional?
5. ¿Deberíamos implementar una capa websockets que nos permita rastrear que la ventana del navegador está abierta, para medir con mayor precisión lo que está sucediendo?

Lo que notará aquí es que califico todo el aspecto técnico en no más del 50%, y eso es para un rol de desarrollador directo. Desarrolladores que son excelentes en algoritmos, pero groseros con juniors en reuniones, no los contrataré. Los desarrolladores que producen código consistente de alta calidad, pero no pueden pensar por sí mismos y hacer preguntas cuando es necesario, no son buenos para mí. Los desarrolladores que pueden escribir la aplicación por su cuenta en un fin de semana y no pueden lidiar con “lusers” y “PHB”, no sirven.

Entonces, trabaje en esas habilidades. No escriba algoritmos, escriba programas. No escriba algoritmos, escriba blogs sobre programación.

¿Estás buscando tu primer trabajo como desarrollador o ya tienes experiencia?

Si ya tiene experiencia, entonces no es muy bueno o no entrevista bien.

Sin embargo, supongo que eres un novato. Si es así, los algoritmos tienen muy poco que ver con el desarrollo; para muchas cosas, solo tiene que buscar el algoritmo. Para problemas difíciles, no está resolviendo problemas de algoritmos estándar, está desarrollando otros nuevos que son específicos del dominio del problema y necesita experiencia en el tema (si está aplicando a una compañía de juegos, ¿sabe algo sobre juegos? , si está postulando a una empresa financiera, ¿sabe algo sobre finanzas?).

Más allá de eso, construir software requiere conocimiento y experiencia sobre cómo estructurar códigos y sistemas, herramientas, construir cadenas, pruebas, empaques, documentación. (Solo saber martillar clavos y girar tornillos no lo califica como carpintero).

Necesita obtener y demostrar algo de experiencia real.

Deberías comenzar a construir cosas amablemente. Los algoritmos no son lo que hacen los ingenieros. Lo que hacemos es escuchar atentamente los requisitos, luego crear un código que cumpla con esos requisitos, al tiempo que implementamos preocupaciones operativas como el registro, las métricas, la capacidad de prueba y el rendimiento.

Escribimos pruebas, escribimos documentación, configuramos sistemas de construcción, automatizamos el empaquetado y la implementación. Hacemos una lluvia de ideas sobre cómo mejorar nuestros sistemas, hacemos una selección de plataforma y marco. Construimos marcos y los abrimos de código abierto.

Cuando entrevistamos a personas, estamos tratando de entender si podrán realizar las tareas anteriores de manera eficiente y bien y si podrán convertirse en roles más responsables y desafiantes. Nuestro nivel de atención sobre su capacidad para equilibrar un árbol binario es bastante bajo.