Algunas respuestas aquí ya son realmente buenas, pero creo que podría ser valioso contar con la perspectiva de alguien que se capacitó para estas entrevistas recientemente y recibió una oferta de trabajo como resultado directo. Así que responderé su pregunta y le diré cómo puede conseguir un trabajo en Google y Facebook en 1 mes (preparación de 1 mes, eso es). Por cierto, la brevedad no es mi fuerte, así que esta publicación puede que te lleve un tiempo terminar, pero prometo que vale la pena, y haré todo lo posible para responder las preguntas que publiques en los comentarios sobre detalles, porque casi definitivamente me olvidaré de mencionar algunas cosas importantes (yo preparado para las entrevistas hace unos 5 meses, así que esto se basa solo en mi memoria).
Voy a detallar cómo me preparé para las entrevistas técnicas en ~ 1 mes, después de lo cual conseguí un trabajo en Facebook. El proceso de obtener una entrevista hasta obtener una oferta probablemente tomará 1-2 meses extra después de eso. Para mi propia experiencia durante el proceso de entrevista real, vea la respuesta de Jimmy Saade a ¿Cómo es el proceso de entrevista de ingeniería de software en Facebook Londres? Tenga en cuenta que esto es para el puesto general de Ingeniería de Software (en mi caso, nuevo graduado), y nada específico como el desarrollador de Android / iOS, o el Ingeniero de Infraestructura, etc.
Lo bueno y no tan conveniente de las entrevistas tecnológicas es que nunca sabes lo que vas a obtener, por lo que debes estar preparado para una gran variedad de posibles temas, algunos de los cuales tienen más probabilidades de ocurrir que otros. . Tocaré estos a continuación y luego describiré algunos tipos de preguntas muy importantes que pueden surgir y que debe estar preparado para tratar.
Digamos que tu entrevista es en un mes. Así es como planearía dicho mes (suponiendo un horario de tiempo completo). Tenga en cuenta que esto es lo que haría (y lo hice, en realidad), por lo que podría no ser el enfoque óptimo para usted, pero le sugiero que trabaje de manera similar y lo cambie un poco en función de cómo cree que comprendería mejor los conceptos (p. Ej. resolver y codificar en paralelo, a diferencia de lo que hice, que es resolver todo y luego codificar todo …)
- ¿Cuál es un buen consejo para un estudiante de ingeniería mecánica de 18 años?
- ¿Qué hace si el campo en el que le gustaría trabajar no se puede hacer profesionalmente a tiempo completo o como pasatiempo?
- Me gustaría abrir una agencia de marketing independiente. ¿Qué es un consejo?
- Cómo hacer que los jóvenes se interesen en obtener asesoramiento de un negocio de educación e información profesional
- ¿Cómo debo elegir entre dos oportunidades de carrera?
Días -∞ a 0: requisitos previos
Supongo que ha tomado un curso de algoritmos y conoce las principales estructuras de datos, incluidos, entre otros: árboles binarios, árboles de búsqueda binaria, tablas hash, montones, pilas, colas, gráficos, listas, intentos … así como todos los algoritmos relacionados con ellos (insertar, eliminar, buscar, encontrar, encontrar máximo, encontrar mínimo …) y la complejidad del tiempo para cada uno de ellos, al menos en un nivel alto. Para los gráficos, debe conocer las búsquedas (BFS y sus propiedades, DFS y sus propiedades, incluida la detección de ciclos y similares) y los algoritmos de ruta más corta (Dijkstra, Bellman-Ford y A *) como mínimo. Si no sabe todo esto, junto con la programación dinámica, necesitará más de un mes. Elija Introducción a los algoritmos (CLRS) y comience a estudiarlos primero. ( Actualización: Publiqué una respuesta aquí: la respuesta de Jimmy Saade a ¿Qué debo saber del libro de la 3ra edición de CLRS si mi objetivo es ingresar a Google? en cuanto a qué partes de CLRS son relevantes para las entrevistas técnicas.) Esta es la parte fácil, ya que es todo académico y se espera que lo sepas todo. La parte que sigue a continuación (Día 1 en adelante) es la parte realmente valiosa que puedo ofrecerle.
También supongo que conoce un lenguaje de programación como C ++ (o Java) y las funciones integradas que realmente lo hacen útil (es decir, STL o sus equivalentes de Java). ( Actualización 2: publiqué información relevante para esto aquí: la respuesta de Jimmy Saade a ¿Cuáles son los conceptos más importantes en C y C ++ que se deben aprender y comprender antes de una entrevista de programación?). Si no conoce STL, dedique tiempo a aprender vectores, mapas, conjuntos, mapas desordenados, conjuntos desordenados, colas, pilas y toda la biblioteca de “algoritmos” (en serio, todo). Estas son esencialmente implementaciones de lo que acaba de aprender en CLRS, por lo que si necesita usar un montón, no comenzará a codificar uno durante una entrevista (solo use un mapa o una cola de prioridad). También necesita saber cómo implementar una lista vinculada, BST y un trie en 5 minutos, lo que es mucho más fácil de lo que parece (solo cree una clase de nodo y una función de inserción y para fines de entrevista, está bien. )
No asumo que sabe algo sobre los siguientes temas: programación paralela, redes de computadoras (HTTP / TCP / IP / Ethernet), sistemas operativos / programación, hilos / procesos / paralelismo / concurrencia, ensamblaje, hardware y lenguajes descriptivos de hardware, o cualquier otra cosa Si bien estos son conceptos valiosos para conocer como informático (como lo son el aprendizaje automático y la inteligencia artificial y otros), las posibilidades de que aparezcan son prácticamente nulas a menos que las establezca como habilidades en su currículum, por lo que su tiempo se gastará mejor en otro lugar (es decir, trabajando en los temas a continuación). Sin embargo, debe tener cierta conciencia de la informática distribuida, así que desplácese hacia abajo hasta la sección Diseño del sistema para eso y asegúrese de leer el documento de MapReduce como mínimo.
Día 1 – El libro
Compre este libro: Elementos de las entrevistas de programación. Uf. Eso fue difícil.
Con toda seriedad, este es el mejor libro sobre el tema en mi opinión, y realmente estoy realmente sorprendido por lo que poca gente lo sabe o lo usa. (No estoy afiliado con este libro). La colección de preguntas es excelente y hasta el punto, es grande (más de 300 problemas, que es lo más que he visto en un libro), se centran en los conceptos correctos (por ejemplo, varios problemas están en la búsqueda binaria, que es muy probable que surja en una entrevista, más que cualquier otro algoritmo), y sus respuestas (y el código proporcionado) son casi todas correctas y excelentes. Digo “casi” porque hay 1 o 2 problemas que tienen soluciones mucho más simples que los detalles del libro, pero no es un problema, especialmente cuando lo comparas con otros libros de entrevistas de programación, que tienen varias respuestas que son francamente incorrectas. Además, la comunidad de soporte en línea es bastante buena, con código Java disponible para todos los problemas (el libro los tiene solo en C ++) y un foro en línea para discusiones en el hogar – Elementos de entrevistas de programación. También renuncian a todas las cosas de “enseñanza” que tienen otros libros donde intentan enseñarte estructuras de notación y datos de gran O, y se centran casi por completo en la parte de los problemas, que es mucho, mucho, mucho, mucho más importante. La notación big-O y las estructuras de datos que debe aprender de CLRS, que es el mejor recurso para ellas, punto. Ningún otro libro, especialmente los libros de entrevistas de programación, se acerca a su calidad en la enseñanza de esas cosas.
También sé (a través de varias fuentes) que varios de estos problemas realmente se preguntan tal como están (o en forma encubierta) durante las entrevistas, lo que muestra cuán puntual es. (Me imagino que una razón para eso puede ser su baja popularidad en comparación con otros libros de entrevistas, ya que las compañías prohíben que las preguntas que están ‘por ahí’ sean formuladas en las entrevistas, por lo que probablemente no verá las preguntas de Cracking the Coding Interview .) Sin embargo, si esto le sucede, le sugiero que se lo diga a su entrevistador, ya que es muy fácil para ellos saber si conoce el problema antes o no, y si simplemente recita la respuesta, no cumple con el propósito de la entrevista. Por suerte para mí, no me preguntaron ninguno de los problemas que había hecho con el libro.
Días 2-14 – Etapa de algoritmos
Repase el libro capítulo por capítulo, un capítulo por día [1], comenzando en el Capítulo 5, terminando en el Capítulo 19. Haga todos los problemas. Todos ellos. (Para ser completamente honesto, podría haber omitido algunos, pero esto fue más por accidente que cualquier otra cosa, y definitivamente me gustaron más del 98% de ellos). No codifique, resuelva solo los problemas (es decir, encuentre el algoritmo ) Dése una fecha límite por problema, dependiendo de cuán difícil sea el problema (por ejemplo, 10 minutos para problemas no ninja [2], 20 minutos para problemas gray-ninja, 30-40 minutos para problemas black-ninja), si No he encontrado la solución para entonces, mira la respuesta y entiéndelo. Si no lo haces, no mejorarás. Es importante pensar en los problemas por su cuenta, porque lo importante es la forma de pensar, ya que no puede ir y recitar el libro el día de la entrevista. Si encontró una solución, asegúrese de que sea correcta y que haya pensado en todos los casos de esquina.
Nota 1: La nueva versión del libro (a la que me vinculé) tiene todos los problemas de los ninjas en un capítulo separado (Capítulo 22). Esto, en mi opinión, es una idea terrible. El libro que tuve tuvo los problemas que actualmente están en Ch. 22 repartidos por el libro, cada uno en su capítulo correspondiente. Le sugiero que revise los problemas ninja relevantes de cada capítulo mientras hace dicho capítulo. Por ejemplo, en el Día 2, haga el Capítulo 5, y los problemas relacionados con el Capítulo 5 en el Capítulo 22. En el Día 3, haga el Capítulo 6, y los problemas relacionados con el Capítulo 6 en el Capítulo 22, y así sucesivamente. Creo que los problemas en el cap. 22 están ordenados en consecuencia (los problemas ninja del Capítulo 5 son lo primero, luego los del Capítulo 6, y así sucesivamente), por lo que esto no debería ser demasiado difícil, pero no estoy 100% seguro porque tengo la copia anterior del libro.
Nota 2: A veces pasaba horas en un solo problema, solo porque pensaba que el problema era realmente interesante e insistía en resolverlo yo mismo. Considero que estos esfuerzos aleatorios son útiles a largo plazo, ya que desarrolla su pensamiento crítico mucho más que los problemas más fáciles, pero también lleva tiempo, por lo que es probable que no pueda hacer esto para cada problema, incluso si lo desea. en absoluto.
Días 14-24 – Etapa de codificación
Repita el libro, esta vez con codificación. Ya conoce las respuestas, por lo que debería poder recordar el algoritmo para cada problema con bastante rapidez (si no lo hace, búsquelo. Ocurre, y puede suceder a veces incluso si previamente había resuelto el problema usted mismo.) Esta es la etapa de codificación, así que no pierda el tiempo derivando algoritmos.
No sugiero que codifique todos los problemas, especialmente si tiene experiencia con ACM-ICPC, TopCoder o Codeforces y similares (y realmente, si está lo suficientemente familiarizado con STL, probablemente tenga un conjunto de habilidades decente). Solo escriba el código para los problemas que considera que tienen algoritmos complejos, una nueva estructura de datos que no ha utilizado antes (por ejemplo, un mapa desordenado para el hash tal vez), problemas con casos de esquina complicados (la búsqueda binaria está en la parte superior de esta lista ya que sus variantes son preguntado a menudo y puede ser mucho más complicado de lo que piensas) o un concepto de programación con el que no te sientes cómodo (esto incluye, pero no se limita a, sobrecarga del operador, comparadores personalizados, funciones hash personalizadas, funciones == personalizadas y mucho más … ) Si un problema le resulta difícil o lo implementó de una manera que considera que no es óptima, consulte las soluciones que ofrece el libro, que son excelentes y limpias, y le enseñará todos los conceptos mencionados anteriormente. Le sugiero que imite un poco su estilo de escritura de código. Algunas notas importantes, si son obvias, son: use nombres de variables descriptivas (ninguna de esas basura de nombre de variable de 1 letra) y sangría correctamente, y no olvide cerrar paréntesis y corchetes.
También le sugiero que codifique todos los problemas del capítulo Algoritmos codiciosos y casi todos los problemas marcados con ninjas. El capítulo de Programación dinámica también es importante si no está familiarizado con DP y puede ser difícil de entender, así que asegúrese de darle su tiempo.
Día 25 – En más preguntas
Entonces, ahora que ha agotado la mejor reserva de preguntas y está lo suficientemente cómodo como para entrar en una entrevista, usted … necesita prepararse aún más. Vaya a Preguntas de la entrevista de Google (Career Cup). Este es un lugar peligroso. Existen algunos problemas muy buenos, pero también hay una clase de problemas que a mi entrenador de ACM le gusta llamar “problemas de Chuck Norris”: problemas escritos donde el OP no tiene idea de lo que está sucediendo y sugiere que el entrevistador requirió tiempo lineal para problemas que claramente no pueden ser hecho en tiempo lineal (como este, que claramente no es tiempo lineal: http://www.careercup.com/questio…), o similar.
Ahora que ha terminado Elementos de las entrevistas de programación, debería poder diferenciar fácilmente entre buenos problemas y problemas terribles. El día 25, revise “todas” (las últimas 20 páginas más o menos) las Preguntas de Google (incluso si se está preparando para Facebook) y haga una lista de las que considere “buenas”, y con “buenas” quiero decir Los problemas que siente podrían haberse planteado en una entrevista de Google. Conoces el estilo de pregunta del libro, por lo que deberías poder decir cuáles son legítimos y cuáles son cuestionables. Supongo que al final debería tener una lista de 80-120 preguntas, algunas simples, otras no tanto.
También tenga en cuenta que muy pocos problemas realmente tienen respuestas correctas publicadas en el sitio, por lo que principalmente tendrá que confiar en su conocimiento para resolverlos y asegurarse de que sean correctos, pero dada su preparación anterior, no encontrará es muy difícil saber cuándo debes estar seguro de tu respuesta y cuándo no. Esto es realmente una preparación valiosa para la entrevista real, que es una experiencia similar.
Días 26-30 – Resolviendo preguntas de la Copa de Carrera
Resuelve todos los problemas que anotaste el día 25. Encuentra el algoritmo. Si siente que es demasiado difícil, busque ayuda. Si cree que es imposible o la mejor solución es el tiempo exponencial, realmente podría ser que el OP se equivocó. Sacúdetelo, pasa a otro problema. Si todavía te apetece, codifica algunos de los problemas más desafiantes.
Varias de las preguntas de Career Cup son similares a las del libro, por lo que no debería tener demasiados problemas con la mayoría de los problemas.
Día 30.5 – Saltar listas (solo Google)
Escuché que Google recientemente se ha acostumbrado a preguntar sobre las listas de omisión (no estoy seguro de por qué). Mira este video:
y entenderlo y conocer el análisis de los tiempos de ejecución esperados. Después de eso, implemente y pruebe su propia Lista de saltos. Hice esto solo para practicar y porque las listas de omisión son interesantes de todos modos.
Para ser sincero, Google puede ser bastante impredecible con sus preguntas a veces, en mi experiencia. Pueden hacer preguntas generales sobre programación orientada a objetos o redes de computadoras, comandos de Linux como grep, cosas teóricas como la prueba del límite inferior de clasificación, preguntas de codificación que se basan en algún concepto matemático que puede haber olvidado resolver, o en profundidad preguntas del lenguaje de programación (por ejemplo, sobrecarga de functores / operadores en C ++). Supongo que depende de su currículum vitae y de lo que usted dice que es competente, por lo que mi consejo es que no ponga nada allí que no sea al menos algo competente. Ayuda tener un título en Ciencias de la Computación o Electricidad e Informática Ingeniería, realmente, solo basada en la gran variedad de posibles preguntas. Sugiero una lectura completa de Obtener ese trabajo en Google (Steve Yegge) y Cinco preguntas esenciales sobre la pantalla del teléfono (Steve Yegge). Probablemente debería conocer la mayoría de los temas tratados aquí (sin embargo, no invertiría mi dinero en cosas como hilos / procesos / paralelismo a menos que lo indique explícitamente en su currículum). La mayoría de las preguntas de codificación en el segundo enlace son creo que es muy fácil llegar a una entrevista, así que no te entusiasmes demasiado y me saltearé la sección “Versión especial de vía rápida”. Es gracioso, pero pensé que era demasiado cínico y fuera de lugar. Su elección del editor de texto, el conocimiento del sistema operativo o el conocimiento de uno o varios idiomas no le harán , en sí mismos, fallar una entrevista.
En una pequeña nota, aunque creo que Google puede hacer muchas preguntas no algorítmicas como la anterior, la mayor parte de la entrevista seguirá siendo estructuras de datos / algoritmos / codificación, por lo que todas las otras cosas mencionadas en el blog de Yegge deberían saberlo, pero No son el foco principal.
Día 31 – Las cosas no técnicas
Bien, entonces estoy engañando un poco agregando el Día 31, pero también deberías tomarte un día más o menos para prepararte para la parte no técnica de las entrevistas, especialmente si estás entrevistando en Facebook, donde hay un programa no técnico entrevista. Primero, prepare las preguntas que desea hacer a sus entrevistadores sobre Facebook y sobre su trabajo y lo que hacen todo el día. Vea mi publicación de Facebook en Londres para obtener más ejemplos sobre esto. En segundo lugar, piense en sus experiencias en la universidad / trabajo / lo que sea: proyectos en los que ha trabajado, equipos con los que ha trabajado o gestionado, conflictos que ha abordado, errores difíciles con los que ha tenido que lidiar, etc. Búsqueda de Google “preguntas de comportamiento” y encontrará miles de posibles preguntas.
Prepare una respuesta no genérica para “Por qué Facebook” (pista: el ritmo rápido y la cultura, el gran talento en la empresa, la misión de conectar el mundo …) y “Por qué Google” (pista: la diversidad de los esfuerzos, el genialidad de búsqueda y Android, la misión de hacer cosas increíbles, la cultura de la empresa …). No me hicieron estas preguntas en ninguna de las dos compañías (para mi desilusión, ya que me apasionaban ambas y no podía esperar para mostrarlas), pero apreté mi interés mientras hacía mis preguntas al entrevistador, así que aproveche esa oportunidad si realmente quieres impartir algo que no tuviste la oportunidad.
Consejos para las entrevistas
Los números 3,4,7,8,9 son los puntos más importantes.
- Puede que estés nervioso antes de una entrevista, pero pasará. Estaba nervioso antes de cada entrevista. Una vez que el entrevistador intervino y comenzamos a hablar, generalmente me divertí mucho porque realmente me encantaba hablar con ellos y resolver este tipo de problemas. Haga su mejor esfuerzo para no estar demasiado nervioso: simule entrevistas y cosas por el estilo. También recomiendo programar entrevistas en un orden de prioridad creciente, para que se acostumbre y descubra sus deficiencias cuando llegue a su empresa más buscada.
- Practique la codificación sin un compilador / en una pizarra / papel. No lo hice, pero tengo la sintaxis de C ++ memorizada y estoy acostumbrado a codificar en un papel en competiciones de ACM, por lo que es posible que no necesite hacer esto si ya se siente lo suficientemente cómodo con su idioma favorito (solo necesita saber un lenguaje bien, por cierto, siempre que sea razonablemente conocido, como C ++ / Java / Python. Te permiten usar el lenguaje que quieras durante la entrevista).
- Las vitrinas pueden matarte. Realmente tienes que practicar para encontrar y lidiar con casos de esquina, y / o reconocer lo que yo llamo “problemas propensos a casos de esquina”. Algunos problemas son muy simples desde el punto de vista algorítmico, pero pueden ser muy difíciles de codificar, y obtuve 2 de estos problemas, una vez en mis entrevistas telefónicas de Google y una vez en mis entrevistas telefónicas de Facebook.
- Después de encontrar el algoritmo, deténgase, haga una pausa y piense en cómo codificarlo, antes de hacerlo realmente. Esto es especialmente cierto para los problemas más difíciles, y habría fallado en una de mis entrevistas si no hubiera hecho esto, y como resultado, nunca habría conseguido un trabajo en FB. También podría haber pasado una entrevista en Google que fallé, si hubiera seguido mi consejo en este paso en ese momento.
- Piense en voz alta acerca de los algoritmos / ideas a medida que los desarrolla. Está bien hacer una pausa y pensar en silencio por un momento, pero no te quedes ahí por 3 minutos sin decir una palabra. Siempre al menos dé la solución simple, que muy bien podría no tener un excelente tiempo de ejecución, pero no le hará daño. Lo hice en todas mis entrevistas sin importar cuán simple fuera la respuesta, pero las dije directamente y noté que probablemente haya una mejor solución, luego procedí a pensar en eso. (por ejemplo: De acuerdo, para buscar una matriz ordenada, podemos escanearla linealmente, pero esta es una solución O (n) y es probable que haya algo más rápido). Además, no seas arrogante al respecto (pregúntate en voz alta hasta que estés seguro de tu método y tengas una prueba aproximada de que tu método funciona). No discutas con tu entrevistador. 99.99% de las veces, tienen razón, y usted está equivocado. Una posible excepción a esto es si están desafiando su código: o bien le están señalando un error o intentan hacerlo parecer así para ver qué tan seguro está en su código y si está de acuerdo ciegamente o protestar porque su código es realmente correcto (si esto sucede, no se asuste, solo piense bien en su respuesta antes de darla).
- No hable a través de su código línea por línea mientras lo escribe. Los entrevistadores saben cómo leer su código y qué son las declaraciones if y los bucles for. Solo hable sobre la estructura general del código (que debería haber mencionado antes de todos modos, según el Consejo # 4) mientras codifica. Sin embargo, mencione lo que está haciendo en intrincadas líneas de código (por ejemplo, si desea probar si ‘x’ es una potencia de 2 a través de “if (x & (x-1)) == 0”, es posible que desee mencionar eso).
- Las preguntas a menudo se especifican con poca precisión, y esta es una gran debilidad de los Elementos de las entrevistas de programación: todos los problemas se especifican por completo, por lo que casi no tiene capacitación en esto. Siempre piense en las preguntas que pueda hacer o en las condiciones que pueden hacer que su algoritmo falle si no es cierto. Algunos ejemplos son: ¿Son todos los números positivos? ¿Son distintos? ¿Cuál es el tipo de entrada (entero / doble …)? ¿Puedes volver a visitar una celda de la cuadrícula? El libro tiene preguntas donde estas propiedades se especifican explícitamente en la pregunta: piense en lo que sucedería si estas condiciones no estuvieran allí: la solución a menudo se rompe.
- No te rindas si no piensas en la respuesta directamente. En mi última entrevista en Facebook, obtuve el problema más desafiante hasta el momento, y me tomó alrededor de 5 minutos llegar a la respuesta, y terminé contratado. Esa fue posiblemente * la * entrevista que me contrató, y también fue la que más disfruté.
- Dos conceptos realmente importantes para conocer bien son la búsqueda binaria (y sus variantes) y la búsqueda en el espacio de estado usando Breadth-First-Search para encontrar la secuencia más corta de ‘movimientos’ (como este problema: Archivo en vivo ACM-ICPC – Kermit the Frog ) Ambos surgen muy a menudo.
- La suerte importa. El proceso de la entrevista no es perfecto, y es posible que no lo superes incluso si eres realmente bueno, ya que depende de tus entrevistadores y de las preguntas que recibas (y en qué tipo de preguntas eres fuerte, etc.). mitigue mucho este factor preparando una gran cantidad, pero siempre está ahí, y es importante saberlo. Le sugiero que lea Obtener ese trabajo en Google (blog de Steve Yegge) si desea obtener más detalles sobre este factor.
- Ignorar Ch. 20 y 21 en el libro. No son geniales (Tal vez lea el capítulo 21 un poco para tener una idea, pero eso es todo.) Desplácese hacia abajo hasta la sección Diseño del sistema si también tiene que prepararse para una entrevista de diseño del sistema.
- Suba menos de lo esperado en su CV (o al menos, no lo venda demasiado), especialmente si lo solicita a través de una referencia. Si escribes ‘experto en C ++’, llamarán a su ingeniero de C ++ más experimentado para que te estrelles y te quemes. Nunca conocí a nadie que tuviera algo relacionado con el subprocesamiento múltiple y el paralelismo en una entrevista para SWE, excepto una persona que lo enumeró como una habilidad. Y he aquí, le preguntaron al respecto, y no le fue tan bien.
- A menudo, obtendrás un problema que es una variante de un problema que has visto antes en el libro o en Career Cup, o es el mismo problema pero en una “forma encubierta” (es decir, está redactado de manera diferente pero tiene el mismo o una solución en su mayoría similar.) Tenga cuidado con estas diferencias sutiles; es posible que descubras (o pienses que has descubierto) la solución para el problema porque lo encontraste muy similar a uno que has visto antes, pero una pequeña diferencia en la declaración del problema en realidad significa que su solución es realmente muy diferente. Como ejemplo, consulte la pregunta 17.5 – Buscar una secuencia en una matriz 2D – en Elementos de entrevistas de programación. Incluye la declaración “Es aceptable visitar una entrada en A más de una vez”. Con él, la solución es DP. Si esa declaración no está incluida (es decir, no es aceptable visitar una entrada más de una vez), la solución es ramificada y no hay ningún DP involucrado en absoluto. Si responde erróneamente a DP en lugar de ramificar y vincular o viceversa, el entrevistador sabrá que ha visto el otro problema antes y cree que acaba de memorizar la solución, por lo que probablemente sea suficiente por sí solo para darle un “no -hire “recomendación de ese entrevistador. (También me atrevería a adivinar que esa declaración no sería declarada por el entrevistador en primer lugar, exactamente por esta razón, y tendría que preguntar si puede visitar una entrada más de una vez, según el consejo # 7. El objetivo es ver si descubrirás o no que hay una gran diferencia en las soluciones dependiendo de la respuesta del entrevistador a esta pregunta).
De nuevo, probablemente olvidé muchas cosas, así que si hay algo específico que quieras saber, deja un comentario. También haré todo lo posible para mantener esta publicación actualizada con cualquier otra cosa importante que recuerde más adelante.
Diseño de sistemas
Aunque yo no tenía uno, me preparé para las entrevistas de Diseño del sistema. Me preparé visitando este sitio: Hired In Tech, que es decente (no excelente) y leyendo varios documentos en este sitio, directamente de Google: Sistemas distribuidos y computación paralela, principalmente el primer documento de MapReduce (casi al final de la página) ) y el papel Chubby. MapReduce es muy importante y realmente te sugiero que lo leas y entiendas cómo funciona. Después de esos pasos, busque bases de datos, específicamente SQL y NoSQL, familiarícese con el teorema CAP, temas de escalabilidad y tal vez lea sobre Hadoop y algunos problemas que puede resolver con él (Hadoop In Practice es un libro decente para estos fines). Pruebe algunas preguntas como la pregunta “Diseñar un acortador de URL” en Hired In Tech, o algo a mayor escala como “Diseñar un motor de búsqueda web” o “Diseñar Google Maps”, todas las preguntas que pueden formularse (consulte también el capítulo 21 del libro para posibles preguntas y una pequeña idea de cómo responderlas, aunque las respuestas del libro no son excelentes.) Pero en general, para la entrevista de diseño del sistema, practicar preguntas es menos significativo que comprender fundamentalmente los conceptos anteriores y saber cómo discuta sobre ellos, ya que la entrevista completa es algo así como una conversación rápida entre usted y el entrevistador, donde él / ella cambiará las especificaciones de las preguntas sobre la marcha para ver cómo maneja los diferentes escenarios.
Consejo final
Entonces, si realmente quieres ese trabajo, tomará algo de tiempo y dedicación, pero espero que sea del tipo agradable. Personalmente disfruté mucho preparando este tipo de preguntas y descubrí que, aparte del trabajo, realmente aprendí mucho y obtuve una gran cantidad de conocimiento de la preparación, y probablemente tú también lo harás.
Mi último consejo es simplemente ir a la entrevista y no estresarse (esto es obviamente más fácil decirlo que hacerlo). Los ingenieros quieren que seas bueno y quieren contratarte; la contratación es un proceso bastante costoso. Algunos pueden ser fáciles y otros pueden ser menos indulgentes, pero en todos los casos, la entrevista es muy similar a una conversación entre dos ingenieros, y eso es exactamente lo que estas empresas se esfuerzan para que sea la entrevista, así que trátelo de esa manera, y si te has preparado bien, se mostrará.
[1] – Un capítulo por día es realmente un poco lento ya que no estás codificando, por lo que para capítulos más cortos como los Capítulos 5, 7, 8, 9, te sugiero que hagas 2 por día, lo cual es factible.
[2] – En Elementos de las entrevistas de programación, los problemas no ninja son problemas estándar, los problemas gris-ninja son algo difíciles y los problemas negro-ninja son difíciles.
Descargo de responsabilidad: esta es mi propia opinión / consejo, y no está respaldada por nadie más de ninguna manera.
