Experiencia de entrevista de Google Bangalore – Part 1

Pantalla inicial del teléfono:

El reclutador me preguntó sobre mis antecedentes y discutió el procedimiento de la entrevista. También me hizo algunas preguntas fundamentales de DS/Algo con respuesta de una palabra, como la complejidad del tiempo de clasificación rápida.

Entrevista telefónica técnica 1:

No salió muy bien ya que tuve problemas para explicar mi enfoque al entrevistador. Era una pregunta de geometría computacional y nunca antes había hecho preguntas de este tipo. Me costó mucho encontrar la solución ingenua porque todo el tiempo supuse que la solución que estaba pensando no funcionaría (nuevamente falta de confianza). Mi nerviosismo se hacía más grande a medida que pasaba el tiempo. Unos 20 minutos después me pidió que codificara lo que ya le había dicho. Después de codificar, señaló casos en los que mi algoritmo fallaría. Como codifiqué de una manera muy estructurada y modular, pude arreglarlo rápidamente, pero aún así, no era completamente correcto.

Recibí la llamada de mi reclutador después de una semana diciendo que era una respuesta mixta: me dijo que no pensé en voz alta pero que me fue muy bien en todas las demás partes, como la estructura de datos y la estructuración del código, y que les gustaría llevar a cabo otra llamada. entrevista.
Bueno, después de la llamada, intenté compilar el código y descubrí con asombro que se ejecutó correctamente y que la respuesta era correcta. Me sentí tan estúpido por no creer en mí mismo todo el tiempo, que a pesar de tener la habilidad y la práctica suficiente, tenía poca confianza. De todos modos, me alegré de tener otra oportunidad.

Entrevista telefónica técnica 2:

Era una especie de pregunta de evaluación de expresión con algunas condiciones. Lo hice usando stack y terminé de codificarlo en 20 minutos. Revisé mi código dos veces pero me perdí un error sintáctico y tuvo que señalarlo. Luego me pidió un seguimiento y lo hice en un par de minutos mientras hacía una función para la lógica central, así que solo tuve que ajustar eso. Fue excelente y, al final, nos quedó suficiente tiempo para charlar.

A medida que se acercaban mis presenciales, mi recuento de problemas de LC fue de  177 a 59 fáciles, 102 medios, 16 difíciles
(comencé a hacer problemas difíciles junto con los medianos después de recibir la invitación porque tenía que subir de nivel en mi preparación. Los problemas difíciles son agotadores y son generalmente una combinación de 2-3 medianos, así que me enfoqué más en los medianos).

Entrevista en el sitio:

Fecha: enero de 2020

Cuando llegué a la oficina, estaba muy nervioso. Pero estoy feliz de que mi reclutador me calmó y me animó para la entrevista.

La ronda 1:

El entrevistador me hizo primero una pregunta de preparación e instantáneamente le dije la solución y las complejidades de tiempo/espacio. Eso me hizo sentir extremadamente relajado. La siguiente pregunta que hizo fue un problema gráfico. Podría ser resuelto por dfs/bfs, discutí por qué bfs sería un poco mejor que dfs. Escribí los pasos algorítmicos antes de codificar y luego la codificación en sí tomó muy poco tiempo. (He escrito este enfoque en detalle en los consejos de entrevista a continuación)

La ronda 2:

El segundo entrevistador me pidió que segregara números dentro de un rango (0 a N) que cumpliera con algunos criterios. Le dije el enfoque iterativo ingenuo para verificar todos los números y luego discutí formas de optimizarlo. Lo resolví retrocediendo para generar solo los números válidos.

Ronda 3 (Googlyness / Comportamiento):

Esta ronda se sintió importante porque muestra su determinación y optimismo en diferentes situaciones. Me gustó que las preguntas estuvieran basadas en escenarios y fueran abiertas.

Ronda 4:

No fue tan bien como mis otras rondas de entrevistas. Era una pregunta de árbol para la que se me ocurrió una solución recursiva, pero no estaba seguro de cómo utilizar correctamente los valores devueltos. Se estaba acabando el tiempo, así que me pidió que codificara todo lo que le había dicho. No pude planificar mi código antes, por lo que tuve pocas dificultades para implementarlo y estaba reescribiendo mi código. Mediante el uso de algunas sugerencias, apenas pude terminar mi código a tiempo. No pudo hacer ningún seguimiento.

Ronda 5:

Era una pregunta de array para la que se me ocurrió una solución dfs pero me quedé atascado. El entrevistador me dio un codazo hacia bfs. Codifiqué la solución bfs y en el seguimiento me preguntó cómo la probaría.

Resultado:  Mis onsites fueron fantásticos, por lo que adelantaron mi solicitud. La aprobación de HC llegó la próxima semana.

Conclusión:

Comencé mi viaje cancelando mi entrevista debido a mi miedo al rechazo, ¡pero ahora me doy cuenta de que fui yo quien me rechazó ese día! Recomiendo encarecidamente a todos:  ten fe en ti mismo y ponte ahí fuera, puedes decepcionarte si fallas, ¡pero estás condenado si no lo intentas!

El aprendizaje es un viaje cuesta arriba y requiere mucha práctica constante. Tengo un trabajo de tiempo completo y guardé mis descansos para hacer Geeksforgeeks y problemas de leetcode. Algunos días fueron ajetreados, pero aún así al menos tuve un problema. Nunca estudié mucho los fines de semana (quería hacerlo pero me daba pereza levantarme de la cama). Así que mantente constante y pronto comenzarás a disfrutar el proceso, de hecho, comenzarás a encontrar excusas para hacer leetcode.

Recursos:

• Estructuras de datos claras:  utilicé los tutoriales de Geeksforgeeks y HackerEarth para comprender la implementación de varias estructuras de datos. Fue bastante explicativo pero breve.
• Clear algos:  dedique algo de tiempo a leer CLRS si desea ser un verdadero programador. Dado que es muy amplio, lo usé cuando necesitaba un conocimiento profundo de la clasificación y la programación dinámica.
• Entrevista de Cracking The Coding (por Gayle Laakmann McDowell) –  ¡Muy, muy útil! Una vez que tenga claras sus estructuras de datos y algoritmos, use este libro para aprender a aplicar el conocimiento de manera práctica mientras codifica. Comience con la primera pregunta y siga avanzando de una en una porque el nivel de dificultad aumenta con cada pregunta (me pareció que sí).
• Programación dinámica:  para soluciones de arriba hacia abajo, dfs/backtracking con memorización funciona bien.
• Para bottom-up: https://www.byte-by-byte.com/dpbook/ (… aunque es muy difícil implementar un DP de abajo hacia arriba en las entrevistas, y nadie espera que lo hagas también)
• Leetcode premium:  vale absolutamente la pena.
• Simulacros:  descubrí que tanto los simulacros de la empresa como los simulacros aleatorios son útiles para medir la preparación. Los simulacros son buenos porque los problemas no tienen la etiqueta de nivel de dificultad, por lo que a veces podía resolver problemas difíciles desglosándolos, lo que de otro modo habría ignorado sabiendo que es difícil.

Consejos para la entrevista:

1. Estructure mejor su código: cree funciones y reutilícelo.
2. ¡Use siempre una pizarra si tiene la opción de elegir entre pizarra y papel para bolígrafo! Se vuelve muy fácil explicar su solución al entrevistador y también abre su mente para pensar en muchas direcciones (debido a su inmensidad).
3. Si tiene dificultades para encontrar la solución ingenua, tome un ejemplo de caso general y resuélvalo. Nunca tome casos especiales para construir soluciones, más bien guárdelos como cobertura de condiciones para más adelante. En esta etapa, no piense en las complejidades de tiempo y espacio, solo resuélvalo porque algunos candidatos no logran hacer ni siquiera eso, por lo que algo es mejor que nada.
4. Discuta las compensaciones de tiempo y espacio después de cada solución que cuente, incluso si el entrevistador no le pregunta, se espera que se la diga usted mismo.
5. Una vez que se discute y finaliza la solución, la codificación debe ser lo más rápida posible. Como no es tan simple, podemos desglosar los pasos de codificación. (Escribo pasos algorítmicos en inglés simple cada vez antes de intentar codificar), como hacer un mapa hash de los datos dados, usar la estructura de datos de la cola, qué argumentos pasar a una función, qué devolver, cómo usar el valor de retorno. Esto ayuda de dos maneras:
   • Puede cubrir fácilmente los casos especiales y los casos extremos porque, en este momento, no está pensando en la solución ni codificando, solo está planeando cómo codificarla.
   • Si algo no está bien, el entrevistador puede señalarlo inmediatamente. Entonces se arregla antes de que comiences a codificar la solución incorrecta.

Por último, ¡muchas gracias a GeeksforGeeks por todas las publicaciones inspiradoras y las soluciones increíbles! Todo lo mejor para todos los que intentan por ahí 🙂