Pregunta de la entrevista de codificación: ¿cómo sentirse lo suficientemente cómodo haciendo una determinada tarea que, naturalmente, no sucedería muy a menudo?

No hay absolutamente ninguna manera de que debas esperar poder practicar todas las preguntas posibles.

No se trata de memorizar nada, se trata de tener suficiente exposición a las estructuras de datos y algoritmos para que pueda resolverlo y rápidamente. Y obtienes esta exposición con la práctica.

• Tome algunos cursos en línea de estructura de datos y algoritmos (por ejemplo, de Coursera , son gratuitos). Aprendí mucho de algunos de estos cursos, que se suponía que eran de pregrado, aunque ya tenía mi título. La diferencia entre las diferentes universidades es tan grande que es absolutamente necesario tomar algunos de estos cursos para asegurarse de que está a la altura.

• Pase algún tiempo en sitios de programación competitivos (por ejemplo , HackerRank , CodeChef , Topcoder ).

• Hay muchos blogs y similares (por ejemplo, CareerCup y GeeksforGeeks.com ) sobre la codificación de preguntas de entrevistas: no lea las soluciones de inmediato, escriba el código de trabajo real en papel y cuente cuánto tiempo le lleva: su objetivo es decir bajo un hora desde que comienzas a leer la pregunta, ya que eso es aproximadamente la duración de las entrevistas.

• Stack Overflow ciertamente puede ayudar, específicamente las etiquetas de estructuras de datos y algoritmos : ni siquiera tiene que responder nada (al principio), solo puede leer las preguntas, tratar de resolverlo usted mismo (intente escribir el código) y luego Lee las respuestas. Si bien es posible que muchas de las preguntas no sean preguntas de entrevista, cosas como encontrar errores en el código de otros también contribuirán bastante a que usted sea un mejor programador.

  Leer y escribir respuestas comprensibles también ayuda mucho a que te expliques mejor, lo cual es muy útil en una entrevista (no publiques respuestas que solo incluyan código).

En términos de consejos genéricos para entrevistas, habla.

Me doy cuenta de que algunas personas pueden pensar mejor en silencio, pero el problema de no decir nada es que el entrevistador no tiene idea de lo que estás pensando. Explica lo que planeas hacer. Si tiene algunas ideas, incluso si cree que son malas o no funcionarán, simplemente compártalas (incluso puede decir que cree que son malas, lo crea o no, pero las malas ideas a menudo ayudan mucho a sus posibilidades). ).

Si no dice nada y no está escribiendo nada, lo más probable es que el entrevistador le haga preguntas para determinar si necesita una pista o qué es exactamente lo que está pasando por su mente.

Sin embargo, debe esperar responder a una pregunta en cualquier momento: es posible que le pidan su motivación para tomar decisiones particulares o que traten de guiarlo en la dirección correcta con algunas preguntas capciosas.

Tenga en cuenta que una solución 'mala', realmente obvia, es mejor que ninguna solución; para su ejemplo, incluso si solo escribe código para recorrer la lista vinculada e insertar los elementos al principio de otra lista vinculada, eso terminaría con una lista invertida, eso es mucho mejor que no dar una solución. Si alguna vez se queda atascado, retroceda dos pasos e intente pensar en alguna forma realmente ineficiente de resolver el problema; con las preguntas de la entrevista, a menudo hay una.

Además, no haga suposiciones: pedir aclaraciones es bueno . Intente activamente no comenzar a escribir código de inmediato: intente encontrar al menos algo en la pregunta que no esté claro que pueda preguntar. Derecha: ¿qué tipo de lista enlazada es? ¿Doble o individual? Puede preguntar sobre la complejidad del tiempo y el espacio, pero para empezar no me preocuparía demasiado, ya que pueden servir como distracciones importantes para una solución algo peor que aún puede considerarse aceptable y terminar consiguiendo el trabajo.

En términos de practicar entrevistas reales, consígase un amigo programador para que haga algunas entrevistas de práctica reales con usted.

Consígase una pizarra (o un bloc de notas también podría funcionar), pídale que le pregunte algo como "invertir una lista vinculada" y escriba el código real en la pizarra. Que él/ella:

• Comprueba que estás pidiendo una aclaración.
• Verifique que no esté callado y sin hacer nada durante demasiado tiempo (no estoy seguro de cuánto tiempo es demasiado, ¿30 segundos?)
• Aparece aleatoriamente con una pregunta sobre por qué tomó una decisión en particular o le pide que explique su código

Podrían obtener sus preguntas de un blog sobre la codificación de las preguntas de la entrevista, por lo que no tiene idea de lo que viene (podría ser una pregunta intencionalmente subespecificada, por lo que debe solicitar una aclaración (bien) o hacer un montón de suposiciones (malo)) .

También mezclaría algunas preguntas de entrevista que no son de codificación (es decir, recursos humanos), ya que es probable que las obtenga en entrevistas reales, y responderlas puede requerir diferentes mentalidades, y está tratando de hacerlo lo más real posible. posible.

Para terminar, practique la escritura de código que funcione completamente sin un IDE, sin probarlo antes de que esté completamente terminado (y luego pruébelo exhaustivamente para asegurarse de que funciona). Si no está acostumbrado a prescindir de toda la ayuda que le brinda un IDE, podría tener dificultades con ese aspecto solo.

Hace décadas, tuve un profesor de ingeniería química que era muy inteligente y muy resistente. Nos diría exactamente lo que nos haría en sus exámenes, nos diría exactamente qué preguntas nos iba a hacer. Y luego, nos eliminaría sin importar cuánto estudiáramos. Fue desconcertante para nosotros, ya que fue humillante: por lo general, no ingresas a la escuela de ingeniería porque eres un tonto.

Los estudiantes finalmente nos dimos cuenta y encontramos la clave:

(1) una buena noche de sueño. En serio. Si va a estar bajo un estrés extremo, reaccionará mejor y con mayor eficacia cuando esté completamente descansado. O lo más descansado que puedas estar cuando vayas a la escuela de ingeniería :)

(2) Espere lo inesperado, pero deje de preocuparse por ello. El problema/limitación con el estudio excesivo y el pensamiento insuficiente es que no hay forma de que practiques para cada eventualidad. El universo de preguntas potenciales es demasiado grande. Lo que puede hacer es reconocer elementos de preguntas que ha estudiado antes y trabajar a partir de ahí.

(3) Sea absolutamente seguro de sí mismo. Si lo jodiste, lo jodiste. Pero si te consideras inteligente, fuerte y listo para cualquier cosa, eso es lo que te conviertes: inteligente, fuerte y listo para cualquier cosa. Así es como te vuelves exitoso. Porque la Diosa del Éxito es voluble con lealtades superficiales y ama a aquellos que son inteligentes, duros y están listos para cualquier cosa.

(4) Trabaja en tus fundamentos. Sigue trabajando en tus fundamentos hasta que puedas hacerlos mientras duermes. No se trata de memorizar y abarrotar, se trata de tener comprensión y control sobre lo que estás haciendo.

Al final del día, ganar es una cuestión de confianza: confianza en sus habilidades, confianza en su entrenamiento, confianza en su conocimiento de sus fortalezas y debilidades, confianza en su capacidad para un autoexamen intransigente pero justo, confianza en que usted Ganaré sin importar qué más pueda salir mal. Y sabes qué, a los empleadores les gustan las personas seguras de sí mismas. Porque saben o deberían saber que están poniendo su destino en manos de sus empleados.

Las preguntas de codificación de la pizarra tienen que ver con la comunicación, no con la memorización . Si bien puede saber cuál es técnicamente la respuesta correcta en términos de código al final, ¿se da cuenta de que lo que realmente se está evaluando aquí es qué tan bien comunica lo que piensa, hace preguntas aclaratorias, qué consideraciones secundarias aporta? y en general, ¿qué tan bien presentas tu respuesta?

Mi sugerencia es tomar al menos un puñado de tareas de programación bastante simples como invertir una lista vinculada, invertir una cadena, crear una cola de prioridad, resolver Fizzbuzz y considerar seguir los pasos de cómo configurar su solución. ¿Qué preguntas haces al principio? ¿Dónde busca aclaración sobre si el tiempo o el espacio es una prioridad para la solución? ¿Qué idiomas usa y hay otros que pueden ser interesantes para ver cómo sería la solución en esos idiomas que quizás no conoce tan bien?

Recuerdo haber recibido un curso acelerado de un reclutador cuando vivía en Seattle, Washington, sobre esto y fue muy útil tener el marco para saber dónde escribiría el código, dónde colocaría los casos de prueba, dónde ¿Declararía las complejidades, etc. para tener un punto de partida para organizarme y avanzar a través del problema, ya que se supone que son lo suficientemente simples como para que si tuviera que resolverlo, probablemente podría hacerlo en la entrevista tal como es? No se trata del truco para encontrar el algoritmo, sino de qué tan bien puedes demostrar que tienes una buena solución al final.

Si desea algo con fines de comparación, considere los problemas de matemáticas en la escuela. En el grado 2 es suficiente acertar el número al final, mientras que en el grado 7 es más importante señalar cuál fue el enfoque que utilizó para justificar su respuesta. Mientras que en el grado 2 el maestro sabe la respuesta y puede reconocer al niño que la encontró, en los grados superiores es más importante poder saber por qué algo es correcto para que alguien no justifique: "Bueno, solo supongo que bien, así que pensé que esto funcionaría..."

Tu trabajo como ingeniero de software no es escribir código, es resolver problemas. A menos que haya salido recientemente de la universidad, esperaría que (léase: cualquier persona competente que solicite un trabajo de programación que requiera experiencia previa) descubra cómo revertir una lista vinculada con un poco de tiempo. ¿Por qué? Porque tendrá que hacer cosas muy similares en su trabajo, pero no cosas que ya existen en alguna biblioteca estándar.

No me den una mierda sobre la presión de la entrevista: es muy probable que su trabajo diario involucre a sus clientes o a su jefe presionándolo constantemente.

Esto puede ser duro, pero las entrevistas no son para que las estudies. Están allí para asegurarse de que pueda hacer su trabajo. Si no puede hacer su trabajo (resolver problemas aleatorios, posiblemente bajo presión), entonces no debería obtener el trabajo .

Estudiar para pasar la entrevista solo para llegar a un trabajo donde no puedes estudiar para cada nuevo problema es solo prepararte para el fracaso.

No deberías tener que practicar todas las preguntas y es probable que específicamente quieran verte trabajar en algo que no hayas practicado específicamente. Ejercicios como ese son útiles porque presumiblemente tienes una idea de cuál es el problema, por lo que les evita perder el tiempo teniendo que exponer todos los detalles, pero como es algo que no haces a menudo, pueden ver un ejemplo. de cómo trabajaría en un escenario de trabajo real donde está programando el código de algo que no ha hecho o que normalmente no hace.

Decir "Puede que no, solo estoy pensando" fue una buena respuesta, siempre y cuando lo dijeras en un tono cortés. La mitad de la razón por la que tiene que hacer un problema como ese es para ver la implementación real que hizo (¿usó demasiadas variables? ¿Tuvo una solución O (n ^ 4) donde estaba presente una solución O (n)? ). En ese caso, haga lo mejor que pueda y si ve un problema en su solución, hágaselo saber (es decir, "Por ahora tengo una función de marcador de posición aquí, puedo hacerla más eficiente con un poco más de tiempo. "). Sin embargo, la otra mitad es solo para ver cómo trabajas. De esta manera, tu respuesta les hará saber eso. Es posible que te hayan preguntado porque querían ver cómo abordas los problemas y en qué cosas piensas. Si obtiene un entrevistador que realmente se enfoca en los detalles y hace preguntas como esa,

Al postularme para puestos de "Ingeniero de software sénior", es muy probable que me hagan una de tres preguntas en algún momento durante el proceso de entrevista (ya sea durante la pantalla del teléfono o en el sitio), que son:

• Implementar una lista doblemente enlazada.
• Implementar una tabla hash.
• Implementar una búsqueda binaria.

Mi sugerencia sería que, como parte de la preparación de su entrevista (antes de cada entrevista), implemente los tres con los métodos adecuados de inserción, búsqueda y eliminación.

Será tedioso al principio, pero después de un tiempo habrá memorizado la estructura básica de cada uno y podrá simplemente escribirlos (o escribir en una pizarra) de memoria.

Puede parecer una pérdida de tiempo, pero simplemente, poder eliminar esos tres de la memoria podría significar que su oferta es 5-10K más alta de lo que sería de otra manera, por lo que consideraría que vale la pena la inversión de tiempo.