Cómo progresar mientras estudias para codificar entrevistas

Quedarse atascado nunca es divertido. Especialmente cuando trabajas muy duro. Y, sin embargo, encuentro que esto le sucede a la gente que se prepara para codificar entrevistas todo el tiempo.

Haces un trabajo constante. Ha pasado por cientos de problemas de práctica y ha reservado una hora todos los días para estudiar. Pero simplemente no estás progresando.

Incluso después de todo este trabajo de preparación, todavía sientes que cada problema es un nuevo desafío que no sabes muy bien cómo resolver. Puede resolver los problemas la mayor parte del tiempo, pero no parece que sea mucho más fácil.

Cuando trabajo con clientes de coaching 1: 1, esta es exactamente la situación en la que los encuentro a menudo. Y en casi todos los casos, una vez que identificamos la cosa (o cosas) que los retienen, experimentan grandes avances. ¡Resolver estos problemas ha conseguido que mis clientes trabajen en Amazon, Bloomberg, Uber y más!

Entonces, ¿qué es exactamente lo que te detiene? ¿Qué le impide hacer el progreso que desea? En este artículo, le mostraré los diez problemas más comunes con los que las personas luchan. Sin embargo, una advertencia justa: puede ser muy difícil identificar estos problemas en uno mismo. Si realmente desea resolver sus problemas, le recomiendo trabajar con un entrenador.

1. Desarrolle una base sólida

Ya he hablado de este tema antes, pero una de las claves más importantes para el éxito en la codificación de entrevistas es tener una base sólida de los fundamentos de la informática.

Con el tiempo, he desarrollado muchas técnicas diferentes para ayudar a mis estudiantes a mejorar la resolución de problemas en sus entrevistas, como el Método FAST. Sin embargo, ninguna de estas técnicas es valiosa si no tiene fundamentos sólidos en su haber.

Por ejemplo, el método FAST está diseñado para ayudar a los estudiantes con la programación dinámica. El primer paso del método FAST es encontrar una solución inicial recursiva de fuerza bruta. Esto es algo que debe poder hacer por su cuenta para que el Método FAST sea de alguna utilidad para usted. Incluso si comprende la metodología, no le ayudará si no sabe cómo obtener esa solución inicial.

Si tiene fundamentos sólidos, entonces la recursividad es algo que no debería ser difícil para usted. Es un tema que surge con la frecuencia suficiente como para que puedas sacarlo cuando quieras.

Tal es el caso de todas las demás estructuras y algoritmos de datos fundamentales. Si no sabe cómo implementar una lista vinculada, no importa cuántos trucos aprenda para resolver problemas de listas vinculadas.

Si no tiene una formación formal en Ciencias de la Computación, o simplemente encuentra que las técnicas recomendadas de resolución de problemas para codificar entrevistas realmente no lo están ayudando, entonces su primer paso debería ser dedicarse a aprender todas las estructuras de datos y algoritmos fundamentales.

La mejor manera de hacerlo es tomar el curso de algoritmos y estructuras de datos de MIT (Python) o Princeton (Java). Compra el libro, haz las tareas y haz los exámenes. Si se esfuerza, puede completar fácilmente el curso en 3 meses o menos, y tendrá una base sólida para seguir adelante.

2. Obtenga más experiencia en codificación

¿Alguna vez ha intentado hacer algo por primera vez? Cuando estaba aprendiendo a tocar la guitarra por primera vez, me tomaba 30 segundos conseguir la digitación de un acorde básico. En teoría, podría tocar cualquier canción si tuviera suficiente tiempo y tuviera las tablas de acordes frente a mí, pero no sonaría muy bien.

A veces trabajo con estudiantes que están en una posición similar con su codificación. Simplemente, aún no han alcanzado un nivel de competencia en el que puedan escribir fácilmente el código en su entrevista.

En teoría, el componente de codificación de la entrevista debería ser la parte fácil. Siempre que haya practicado en una pizarra, la parte difícil de su entrevista debe ser desarrollar una solución en primer lugar antes de escribir una línea de código. Si esto no es cierto, probablemente deba mejorar sus habilidades de codificación.

También hay algunos grupos que se ven más afectados por este problema que otros. Principalmente, aquellos que tienen menos experiencia en codificación. A menudo veo graduados de bootcamp, estudiantes de maestría que se cambiaron a Ciencias de la Computación para su maestría de un campo diferente, o gerentes a largo plazo que simplemente no han codificado en un tiempo que luchan más con la codificación.

La clave aquí es simplemente obtener más práctica de codificación, e idealmente hacerlo en un entorno en el que obtenga buenos comentarios sobre su código. Una de las mejores formas de hacerlo es contribuyendo a proyectos de código abierto. Esta no solo es una excelente manera de mostrar su experiencia, sino que también obtendrá el beneficio de revisiones exhaustivas del código y aprenderá a trabajar en un entorno de producción.

Si es nuevo en el trabajo con código abierto, First Timers Only es un gran recurso para aquellos que buscan comenzar. Comparten tutoriales sobre cómo contribuir y han compilado una lista de proyectos potenciales que serían buenos para los principiantes.

3. Aborde estratégicamente cada pregunta de la entrevista

Al entrar en batalla, cualquier general que espere triunfar tiene un plan detallado. Si desea tener éxito en su entrevista, también debe tener un plan detallado.

El plan más común que veo para resolver problemas de entrevistas se parece a lo siguiente:

  1. Mira el problema
  2. Piensa en el problema
  3. Ven con una solución
  4. Escribe la solución
  5. Éxito

Sin embargo, ¿notas algún problema aquí? Con suerte, lo primero que preguntaste fue "¿Cómo puedo encontrar una solución?" Este plan carece por completo de cualquier tipo de estrategia para encontrar la solución. Asume que la solución simplemente aparecerá.

Y así es como la mayoría de la gente piensa sobre los problemas de las entrevistas. Memorizan toneladas de soluciones con la esperanza de que una de ellas sea lo suficientemente similar al problema al que se enfrentan en su entrevista como para que la solución se materialice mágicamente.

Esto es arriesgado en el mejor de los casos.

Una forma mucho mejor de entrevistar es tener un plan de juego claro sobre cómo abordará cada entrevista y cada problema dentro de la entrevista. A continuación, se muestra un esquema general de cómo puede abordar una entrevista de una hora:

[0: 00–0: 05] Póngase cómodo y asegúrese de comprender completamente el problema que están planteando. Trabaje con las entradas de ejemplo proporcionadas.

[0: 05–0: 10] Encuentre una solución de fuerza bruta para el problema. No hay codificación en este punto, solo hable y haga dibujos si lo encuentra útil. Si no encuentra una solución de fuerza bruta, intente resolver el problema a mano y traducir su proceso para resolverlo en un algoritmo.

[ 0: 10–0: 15] Optimice su solución. Tómese estos 5 minutos para encontrar la mejor solución absoluta que pueda en este período de tiempo. Al comparar soluciones, considere las complejidades del tiempo.

[0: 15–0: 35] Codifique su solución. Incluso si no es óptimo, es mejor tener una solución completa, no óptima que una solución óptima incompleta.

[0: 35–0: 50] Pruebe su código y solucione cualquier problema. Esto es muy importante. No importa si su código no es perfecto la primera vez, pero es mejor que pueda identificar los errores.

[0: 50–1: 00] Preguntas para su entrevistador.

Siguiendo estos pasos, logrará dos cosas simultáneamente. Primero, presupuesta su tiempo de manera efectiva. Lo más frustrante del mundo es quedarse sin tiempo cuando sabes cómo resolver el problema.

En segundo lugar, estos pasos lo ayudarán a asegurarse de que siempre llegue a una solución. Al comenzar con la solución de fuerza bruta y optimizar, casi puede garantizar que al menos se le ocurrirá alguna solución. Muchas veces, la solución más óptima no es necesaria si le va bien en el resto de la entrevista.

4. Considere diferentes posibles soluciones

¿Sabías que la mayoría de las preguntas de las entrevistas tienen más de una solución correcta? Lo sé, sorpresa, ¿verdad? Sin embargo, toneladas de personas encuentran una solución y luego simplemente se detienen allí sin buscar más.

Esto siempre me decepciona. Muchas veces, hay otra solución que hubiera sido incluso mejor y estaban tan cerca. O tal vez había soluciones comparables que tenían diferentes compensaciones.

Por ejemplo, considere este problema:

  • Una solución tiene O(n)complejidad temporal y O(1)complejidad espacial
  • Otra solución tiene O(log n)complejidad temporal y O(log n)complejidad espacial

¿Cuál de estas soluciones es mejor?

Bueno, eso depende de lo que realmente estemos buscando. Si tenemos un gran conjunto de datos y poca memoria, la primera solución podría ser mejor. Sin embargo, si la memoria no es un problema, obviamente queremos optar por la segunda solución.

La clave aquí es que, si bien en algunos casos puede haber una "mejor" solución, hay muchos más problemas en los que puede hacer diferentes concesiones y debe decidir cuáles hacer. Como entrevistadora, me encanta ver candidatos que sopesan las diferentes posibilidades.

Cuando esté buscando soluciones, tómese un momento para pensar en otras formas en que podría resolver el mismo problema. ¿Podría hacer concesiones que mejorarían el uso del espacio en relación con el tiempo o viceversa?

Finalmente, siempre debe considerar la complejidad de espacio y tiempo de cada solución que se le ocurra. Esto le brinda una forma objetiva de evaluar qué soluciones son mejores que otras y le ayuda a tomar una decisión más informada sobre qué solución elegir. Si tiene varias soluciones que son comparables, hable con su entrevistador y decida en colaboración cuál sería el mejor enfoque.

5. Comience con la solución de fuerza bruta

Ya mencioné esto de pasada en el consejo 3, pero uno de los errores más grandes que cometen las personas cuando intentan resolver los problemas de las entrevistas es que intentan inmediatamente encontrar la solución más óptima al problema.

Pero déjeme preguntarle esto: ¿Qué es mejor, una solución de fuerza bruta o ninguna solución?

Te diré que encontrar una solución de fuerza bruta es 1000% mejor que no encontrar una solución en absoluto. Y si comienza tratando de encontrar inmediatamente la solución óptima, es fácil quedarse atascado y terminar sin una solución completa al final de la entrevista.

Si bien en realidad no tiene que codificarlo, le recomiendo al menos mencionar brevemente cómo podría resolver el problema con una solución de fuerza bruta antes de continuar para tratar de optimizar su solución. Esto logra dos cosas importantes:

  1. Te da un plan alternativo. Si intenta optimizar su solución y falla, puede detenerse después de 5 o 10 minutos y simplemente codificar su solución de fuerza bruta. Aún puede pasar la entrevista. No todos los problemas tienen soluciones óptimas.
  2. Te ayuda a aclarar el problema. Definir una solución de fuerza bruta puede ayudarlo a comprender exactamente lo que implica encontrar una solución a este problema. Eso es clave. Comprender el problema de esta manera profunda facilitará la optimización.

Intentar encontrar inmediatamente una solución óptima puede parecer el enfoque correcto porque ahorrará un tiempo valioso. Sin embargo, encuentro que la confusión que resulta de adoptar este enfoque a menudo desperdicia mucho más tiempo del que gana.

Comenzar con una solución de fuerza bruta le brinda claridad y un punto de partida para facilitar todo lo demás.

6. Planifique la solución completa antes de codificar

Hay algunas pizarras súper elegantes por ahí. Pero lo más probable es que la pizarra que vaya a utilizar no tenga la opción de copiar y pegar. Eso significa que desea tener un buen esquema de su código antes de escribirlo.

A menudo, las personas se sumergen directamente en la escritura de código tan pronto como se les pregunta un problema en su entrevista. Ahora está totalmente bien si desea seguir adelante y definir su método por adelantado, pero esa debería ser la extensión del código que escriba hasta que haya resuelto completamente la solución. Escribir más código que ese es un error crítico por dos razones.

Primero, como dije, las pizarras blancas no tienen la función de copiar y pegar. Eso significa que si desea mover líneas de código, debe borrarlas y reescribirlas o dibujar flechas por todos lados. Realmente no quiere que su pizarra se vea así:

Mantener la pizarra organizada es más fácil tanto para usted como para su entrevistador. Es más fácil para ellos entender su solución y es mucho más fácil para usted hacer un seguimiento de lo que está sucediendo. Y si decide simplemente reescribir cosas en su lugar, perderá una tonelada de tiempo valioso.

El otro problema de comenzar a codificar desde el principio es que puede bloquearlo en una forma específica de pensar sobre el problema. Hablaremos de esto más en el punto 7, pero esto puede ser increíblemente perjudicial para el desempeño de su entrevista.

Imagínese que ve un problema y de inmediato se le ocurre una solución. Empiezas a codificarlo, pero te das cuenta de que ya no es óptimo. Es poco probable que desee borrar todo y empezar de nuevo. E incluso si lo hace, quedará atrapado en ese modo de pensar.

Hay problemas en los que la solución óptima no está relacionada en absoluto con la solución de fuerza bruta y los intentos de optimizar la solución de fuerza bruta fallarán. Si espera para comenzar a codificar, evita encerrar su mente en esa única forma de ver el problema.

Estas preocupaciones son la razón por la que siempre sugiero que comprenda completamente la solución que desea codificar antes de escribir el código. Haga dibujos, escriba pseudocódigo, haga lo que sea necesario para comprender la solución. Una vez que comiences a codificar, debería ser trivial porque ya sabes exactamente qué escribir.

7. Tenga en cuenta el panorama general

Uno de los mayores problemas que veo para los desarrolladores más experimentados es que se quedan totalmente atrapados en la maleza con un problema. Empiezan a obsesionarse sobre si el ciclo debería ser <; N or &lt; = N y no puedo averiguar cuál es el enfoque correcto.

Este es un ejemplo perfecto de perder el bosque por los árboles. La pregunta que están tratando de resolver se convierte en una de "¿Cómo escribo este bucle correctamente?" en lugar de "¿Para qué sirve este bucle en el contexto general de mi código?"

Un ejemplo perfecto de esto es un problema en el que intenta utilizar la estructura de datos incorrecta. Digamos que está almacenando los valores indexados 1-Ny decide que quiere usar un HashMap. Puede insertar 1 -> value 1, 2 ->value2 y así sucesivamente.

Pero ahora, cuando desee iterar sobre ellos en orden, será una molestia porque tendrá que obtener todos los elementos del HashMap y ordenarlos. Sin embargo, si dio un paso atrás y miró lo que realmente está tratando de hacer, solo desea almacenar el valor en cada índice e iterar a través de ellos. Una matriz sería una estructura de datos mucho más fácil de usar.

Puede que ahora estés pensando: "Nunca haría algo tan estúpido como eso", pero créame, sucede todo el tiempo. Su proceso de pensamiento no es lineal cuando está resolviendo problemas, por lo que es posible que haya pensado que necesitaba un HashMap debido a alguna otra línea de pensamiento que desde entonces ha abandonado.

Por eso es tan importante detenerse de vez en cuando, especialmente si comienza a hacer algo que parece desafiante y mira hacia atrás para ver el panorama general de lo que está tratando de hacer. Siempre que esté haciendo algo que parezca innecesariamente complicado, observe su objetivo final y vea si puede simplificar su enfoque.

8. Utilice la abstracción a su favor

Me encanta preguntar sobre problemas complicados de entrevistas. Si un problema involucra varios componentes diferentes, usted, como entrevistador, obtiene una gran comprensión de cómo un candidato maneja su pensamiento cuando hay tanto de qué tratar a la vez.

La clave para resolver con éxito estos problemas es utilizar la abstracción. En esencia, esto significa dividir su código en funciones más pequeñas con propósitos más específicos.

Considere un ejemplo simple. Digamos que queremos imprimir una lista enlazada en orden inverso. Después de trabajar en este problema, nos damos cuenta de que hay una O(n)solución de tiempo y espacio para el problema usando una pila (empuje cada elemento a la pila mientras iteramos sobre la lista y luego sacamos cada elemento e imprimimos), pero podemos resolver el problema en O(n)tiempo y O(1)espacio invirtiendo la lista enlazada.

Ahora sería bastante fácil revertir la lista vinculada en nuestro código, pero ¿y si tuviéramos una función para hacer eso por nosotros? Eso facilitaría mucho nuestras vidas. Simplemente llamamos a la función en la lista vinculada, iteramos sobre todo en la lista y lo imprimimos, y luego revertimos la lista nuevamente para devolver nuestra entrada al estado original.

Con esa lógica, ahora podemos aislar el proceso de revertir una lista vinculada y pensar cómo hacerlo de manera efectiva. Si bien este problema es un ejemplo muy simple, es fácil ver cómo esto reduce la cantidad de complejidad en la que tenemos que pensar en un momento dado.

Con problemas más complicados, te recomiendo que te hagas la pregunta "¿Qué función, si existiera, me facilitaría la vida en este momento?" Si hay una función o funciones claras, escriba su código asumiendo que esas funciones ya existen. Luego, puede volver atrás e implementar esas funciones, ahora que el resto de su código ya funciona.

Esto tiene varias ventajas:

  1. Si te quedas sin tiempo, todavía tienes un código que básicamente funciona. La abstracción le permite concentrarse en la estructura general sin tener que atascarse en las minucias. Si tiene tiempo adicional, puede preocuparse por las minucias, pero incluso si no lo tiene, su entrevistador tiene claro que sabe lo que pasa.
  2. Claridad de pensamiento y código. Dicen que un escritorio despejado significa una mente despejada y lo mismo ocurre con el código. Cuanto mejor organice su código y lo divida en componentes manejables, más fácil será pensar en ello.

Encuentro que cuanto más complicado es el problema, más valioso puede ser dividir las cosas en componentes manejables.

9. Pruebe su código

Cuando hacemos algo nuevo, tendemos a olvidar muchas de las cosas que ya sabemos. Asumimos que las cosas que ya sabemos no se aplican.

Considere este ejemplo: he estado aprendiendo a tocar la guitarra en mi tiempo libre. Estaba luchando por progresar, así que le pedí ayuda a mi maestro y me sugirió que escribiera algunas metas sobre lo que quería lograr. “DUH”. Escribo sobre este tipo de cosas todo el tiempo, pero no logré establecer la conexión entre la preparación de entrevistas de codificación y la práctica de guitarra.

De la misma manera, encuentro que muchos estudiantes olvidan aplicar las mejores prácticas que conocen de la codificación del mundo real a sus entrevistas. Asumen que la codificación de entrevistas es totalmente diferente, por lo que las cosas que harían normalmente no se aplican.

Una de las cosas que la gente olvida todo el tiempo es probar su solución de entrevista. Pero, ¿alguna vez comprometería código en el mundo real sin probarlo a fondo primero?

Prueba su código porque quiere asegurarse de que sea correcto y que haga lo que cree que debería hacer. Esto es aún más importante en el entorno estresante de una entrevista porque es más propenso a cometer errores.

La clave para probar sus soluciones es revisar el código línea por línea, rastrear los valores de cada variable y "ejecutar" el código de manera efectiva. Si acaba de leer el código a un alto nivel, puede pasar por alto fácilmente problemas más pequeños con su código. Grabé un video que demuestra exactamente cómo recorrer y probar su código.

Encuentro que muchos estudiantes se estresan por que su código sea perfecto la primera vez, y aunque esta es una buena aspiración, rara vez sucede. Casi nunca sucede en el mundo real, entonces, ¿por qué esperarías que sucediera en el ambiente más estresante de la entrevista? Sin embargo, si prueba su código a fondo, puede corregir cualquier error y aún así terminar con una solución A +.

10. Obtenga buenos comentarios

Hacer entrevistas del mundo real es una excelente manera de mejorar en las entrevistas. Puede sentirse más cómodo con la experiencia y darse muchas oportunidades para tener éxito. Una estrategia que se recomienda a menudo es programar un montón de entrevistas con las personas que menos te emocionan primero. De esa manera, puede practicar entrevistas en las que realmente no le importa el resultado, de modo que esté más preparado cuando lleguen las entrevistas importantes.

Si bien creo que esta estrategia tiene méritos, hay un defecto fatal: las empresas son notoriamente malas a la hora de darte comentarios significativos.

“Entonces”, podrías decir, “¿A quién le importa? Puedo juzgar mi propio desempeño ".

Bueno, sí, eso es cierto, pero puede ser muy difícil juzgarse a sí mismo. No sabe qué criterios está buscando su entrevistador (es posible que obtener una solución óptima a un problema no sea suficiente). Y si está luchando por tener éxito, es probable que haya algo que no esté viendo.

Es por eso que las entrevistas simuladas y, además, idealmente trabajar con un entrenador, son tan importantes. Las entrevistas simuladas le brindan la oportunidad de obtener comentarios detallados sobre su desempeño. El entrevistador también puede decirle si hay cosas que no notó

Si realmente quieres hacerlo bien en tus entrevistas, también te recomiendo trabajar con un entrenador además de las entrevistas simuladas. Las entrevistas simuladas son puntos de datos individuales. Te dicen que en un problema en particular en un momento determinado, lo hiciste bien o mal. Sin embargo, un entrenador puede ver todos estos puntos de datos y ayudarlo a establecer conexiones. Pueden ayudarlo a ver las cosas específicas en las que necesita trabajar para mejorar diferentes aspectos del desempeño de su entrevista.

En última instancia, las entrevistas simuladas le brindan puntos de datos y los entrenadores lo ayudan a conectar los puntos. Obtener este tipo de comentarios es la mejor manera de acelerar el progreso de su entrevista.

Una y otra vez, veo que la gente se estanca en sus entrevistas. Y casi siempre es por una de las razones descritas anteriormente. Si no está logrando el tipo de progreso que desea, lea este artículo con atención. Identifique sus áreas problemáticas y trabaje para corregirlas. Con el tiempo, podrá refinar su entrevista y comenzar a recibir las llamadas que desea escuchar.