Contenido esencial y cómo resolver algoritmos
😉 Contenido esencial y como resolver estas preguntas
Generalmente hablando, las entrevistas técnicas no se basan en pruebas para asesorar tus conocimientos - en general están basadas en tus habilidades para resolver algoritmos. Se intuye de que los candidatos ya tienen los conocimientos fundamentales necesarios para poder resolver preguntas difíciles de algoritmos - ya que recurrentemente necesitaran estos conocimientos para hacer su trabajo.
👽 Que es necesario conocer?
Hay conceptos que son fundamentales conocer. Estos no solo te servirán para entrevistas pero en tu carrera como programador en general. Hay estructuras de datos, formas de escribir algoritmos y conceptos claves que consideramos esenciales al momento de entrevistar para compañías con una fuerte cultura de ingeniería.
Estructuras de datos | Algoritmos | Conceptos |
---|---|---|
Linked Lists | Breadth First Search | Manipulación de Bits |
Trees | Depth First Search | Memoria (Stack vs Heap) |
Stacks & Queues | Binary Search | Recursion |
Heaps | Merge Sort | Dynamic Programming |
Vectores / ArrayLists | Quick Sort | Big-O Notation |
HashTables |
Si no te sientes cómodo con las estructuras de datos en la tabla anterior te recomendamos que aprendas a implementarlas desde el principio. Saber las complejidades y detalles de cada una serán de gran utilidad durante tu carrera.
Es importante apuntar que en general HashTables serán extremadamente importantes y es bueno sentirse muy cómodo con ellas.
😶 Cómo resolver estas preguntas?
Es importante que intentes resolver estos problemas por tu cuenta primero - la única forma de volverse buen programador es practicando. No hay tal cosa como memorizarse soluciones cuando viene a ser buen programador.
💣 Tips para resolver estos problemas
- Para cada problema intenta resolverlo por tu cuenta y no ver la solución. También te daremos consejos de como podrías resolverlos - pero aun así te recomendamos utilizar la menor cantidad de ayuda posible.
- Escribe código o pseudo código en papel. Muchas entrevistas y debates de algoritmos serán así y no tendrás el lujo de tener syntax highlighting y otras ventajas que tendrías en un editor de código.
- Has pruebas de tu código en papel, recuerda pensar en todos los casos posibles, errores, capacidades máximas, etc.
- Después pon tu código en el editor y intenta empezar a detectar tus errores, has una lista de ellos y velos corrigiendo poco a poco.
📑 Flujo de como resolver un problema
- Escucha o lee bien la pregunta.; asegúrese de clarificar cualquier cosa de la cual no te sientas seguro. Presta especial atención a los detalles como si un Array esta ordenado o no, ya que la solución mas optima podría ser diferente a que si estuviera sin ordenar. O si te dicen que diseñes un algoritmo que sera utilizado repetidas veces en un servidor - ya que puede que la solución sea diferente a que si un algoritmo solo sea corrido una vez.
- Dibuja un ejemplo; asegúrese de que sea lo más cercano posible a un ejemplo de verdad. Muchas personas cometen el error de dibujar un ejemplo muy pequeño o muy perfecto, cuando en la realidad lo que le interesa a la gente que lea tu algoritmo, es la habilidad que tienes de cubrir todos los casos posibles.
- Escribe una solución a fuerza bruta; No tengas miedo de escribir una solución terrible o incluso incompleta, ya que nadie espera que escribas el algoritmo perfecto a la primera. Tener incluso una solución incompleta te puede llevar a tener una solución no optima. Con una solución bruta puedes empezar a optimizar la complejidad del código y la complejidad del espacio y tiempo del algoritmo.
- Optimización; es lo que deberías estar pensando siempre después de pensar en la primera solución que funcione. La siguiente sección de esta pagina se dedica enteramente a explicarte técnicas para optimizar. Pero cosas en las que deberías de estar pensando son estas:
- Busca cualquier detalle que te hayan dado que no estes utilizando - seguramente te lo hayan dado por alguna razón.
- Utiliza varios ejemplos, aveces simplemente escribir un ejemplo completamente distinto te puede ayudar a encontrar diferentes formas de ver el problema.
- Resuelve incorrectamente; esto es algo que me llevo mucho tiempo comprender al momento de hacer soluciones - pero extremadamente valioso. Al igual que cuando escribes una solución no optima - eso te lleva a optimizar la solución, escribir una solución incorrecta te empieza a poner en el camino a una solución correcta.
- Has comparaciones entre tiempo y espacio. Muchas veces guardar algo de estado localmente te llevaran a hacer menos computaciones y por ende optimizar el runtime.
- Precomputa información. Hay alguna forma de reorganizar la data para que el runtime sea menor?
- Piensa sí sera mejor con un HashTable. Esto es algo que no deberías de olvidar en entrevistas ya que viene de forma recurrente.
- Piensa sí se puede escribir en una manera que tenga un mejor runtime.
- Visita de nuevo tu solución; y lee con atención el código o pseudo-codigo que has escrito. Asegurese que estes seguro de qué pasa con las variables que estes utilizando, que entiendes muy bien el problema y la solución que quieres implementar.
- Implementa; Ahora que tienes una buena idea de cómo solucionar el problema tienes que empezar a enfocarte en escribir buen código. Por esto me refiero a que tengas en cuenta que tu código sea modular. Chequea si hace falta escribir errores - si no tienes tiempo durante la entrevista por lo menos pon un comentario. Utiliza nombres sensatos para variables y no variables como a, b, i,j, etc. Excepto si estas dentro de un loop.
- Prueba; Asegurarte de que tu código ha sido probado con suficientes ejemplos como los que has escrito al principio. Has una leída conceptual - asegurándote de qué entiendes cada linea del código y que sirven un propósito. Asegurese de que si hay algo en el código extraño como
// x = length / 2
// for(i = 1, …), etc.
Que puedas explicar por qué es asi. Por ultimo asegúrese de que tu código tiene formas de lidiar con casos especiales, por ejemplo null checks, si un array solo tiene un elemento, numero negativos, etc.