Algunas respuestas aquí ya son realmente buenas, pero creo que podría ser valioso tener la perspectiva de alguien que se capacitó para estas entrevistas muy recientemente y obtener una oferta de trabajo como resultado directo. Así que voy a responder tu pregunta y decirte cómo puedes conseguir un trabajo en Google y Facebook en 1 mes (es decir, 1 mes de preparación). Por cierto, la brevedad no es mi fuerte, así que esta publicación podría tardar un poco en llegar, pero prometo que vale la pena, y haré todo lo posible para responder las preguntas que publique en los comentarios sobre detalles específicos, porque casi definitivamente voy a olvidar mencionar algunas cosas importantes (I 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 aproximadamente 1 mes, después de lo cual conseguí un trabajo en Facebook. El proceso de obtener una entrevista hasta llegar a una oferta probablemente tomará 1-2 meses adicionales 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 la posición general de Ingeniería de software (en mi caso, nuevo graduado), y nada específico como desarrollador de Android / iOS, o ingeniero de infraestructura, etc.
Lo interesante y no tan conveniente de las entrevistas con tecnología es que nunca se sabe lo que va a obtener, por lo que debe estar preparado para una gran variedad de temas posibles, algunos de los cuales es más probable que ocurran más que otros. . Abordaré estos puntos a continuación y luego delinearé algunos tipos de preguntas muy importantes que pueden surgir y que debería estar preparado para enfrentar.
Así que digamos que su entrevista es en un mes. Así es como planearía dicho mes (asumiendo un horario de tiempo completo). Tenga en cuenta que esto es lo que yo haría (y lo hice, en realidad), por lo que puede que no sea el enfoque óptimo para usted, pero le sugiero que trabaje de manera similar y lo cambie un poco en función de cómo crea que entendería mejor los conceptos (por ejemplo, Resolver y codificar en paralelo, a diferencia de lo que hice, que es resolver todo y luego codificar todo …)
- Puse en marcha mi sitio de comercio electrónico hace 2 meses, pero no obtengo tráfico. ¿Qué puedo hacer? ¿Dame alguna sugerencia o consejo?
- ¿Cuáles son algunos de los grandes pasatiempos o cosas para pasar mi tiempo?
- Estoy teniendo un momento difícil con la pornografía. ¿Qué debo hacer al respecto?
- Como saber si estoy recibiendo un mal consejo.
- Si alguien estuviera pidiendo consejo sobre algo inmoral, ¿le daría un consejo legítimo?
Días -∞ a 0 – Prerrequisitos
Supongo que ha tomado un curso de algoritmos y conoce las principales estructuras de datos, incluidos, entre otros, árboles binarios, árboles binarios de búsqueda, tablas hash, montones, pilas, colas, gráficos, listas, intentos … así como todos los algoritmos relacionados con ellos (insertar, eliminar, buscar, encontrar, encontrar max, encontrar min …) y la complejidad del tiempo para cada uno de ellos, al menos en un nivel alto. Para los gráficos que necesita 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 tercera edición de CLRS si mi objetivo es ingresar a Google? con respecto 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 usted lo sepa todo. La parte que sigue a continuación (Día 1 en adelante) es la parte realmente valiosa que puedo ofrecerle.
También asumo que conoces un lenguaje de programación como C ++ (o Java) y las funciones integradas que lo hacen realmente útil (es decir, STL o sus equivalentes de Java). ( Actualización 2: publiqué información relevante a esto aquí: la respuesta de Jimmy Saade a ¿Cuáles son los conceptos más importantes en C y C ++ que deben aprenderse y entenderse antes de una entrevista de programación?). Si no sabe STL, dedique tiempo a aprender vectores, mapas, conjuntos, mapas desordenados, conjuntos no ordenados, colas, pilas y toda la biblioteca de “algoritmos” (en serio, todo). Estas son esencialmente implementaciones de lo que acaba de aprender en CLRS, de modo 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 enlazada, BST y un trie en 5 minutos, lo cual es mucho más fácil de lo que parece (solo construya una clase de Nodo y una función de inserción y, para propósitos de entrevista, está bien. )
No asumo que sepa algo sobre los siguientes temas: programación paralela, redes de computadoras (HTTP / TCP / IP / Ethernet), sistemas operativos / programación, subprocesos / procesos / paralelismo / concurrencia, ensamblaje, hardware y lenguajes descriptivos de hardware, o cualquier otra cosa. Si bien estos son todos conceptos valiosos que debe conocer como científico informático (como lo son el aprendizaje automático y la inteligencia artificial y otros), las probabilidades de que surjan son casi nulas a menos que las indique como habilidades en su currículum, por lo que es mejor dedicar su tiempo a otra parte (es decir, trabajando en los temas a continuación). Sin embargo, debe tener cierta conciencia de la computación distribuida, así que desplácese 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 en realidad estoy realmente sorprendido de que la gente tan pequeña lo sepa o lo use. (No tengo ninguna afiliación con este libro). La colección de preguntas es excelente y al 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 programación de entrevistas, que tienen varias respuestas que son totalmente incorrectas. Además, la comunidad de asistencia en línea es bastante buena, con el código Java disponible para todos los problemas (el libro los tiene solo en C ++) y un foro en línea para discusiones en Inicio – Elementos de entrevistas de programación. También renuncian a todas las cosas de ‘enseñanza’ que otros libros tienen donde intentan enseñarte la notación de gran O y las estructuras de datos, y se enfocan casi completamente en la parte de problemas, que es mucho, mucho, mucho, mucho más importante. La notación de la gran O y las estructuras de datos que debe aprender de CLRS, que es el mejor recurso para ellos, punto. Ningún otro libro, especialmente no los libros de programación de entrevistas, 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 en realidad se preguntan como están (o de forma encubierta) durante las entrevistas, lo que muestra qué tan bien está. (Me imagino que una razón 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 “ahí fuera” se pregunten en las entrevistas, por lo que es probable que no vea las preguntas de Cracking the Coding Interview .) Sin embargo, si esto le sucede a usted, 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 acaba de recitar la respuesta, esto anula 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 los algoritmos.
Revise el libro capítulo por capítulo, un capítulo por día [1], comenzando en el Capítulo 5 y terminando en el Capítulo 19. Resuelva todos los problemas. Todos ellos. (Para ser completamente honesto, podría haber omitido algunos, pero esto fue más por accidente que por cualquier otra cosa, y definitivamente me gustó más del 98% de ellos). No codifique, resuelva los problemas solo (es decir, encuentre el algoritmo ). Concédase una fecha límite por problema, dependiendo de lo difícil que sea el problema (por ejemplo, 10 minutos para problemas no ninja [2], 20 minutos para problemas de ninja gris, 30-40 minutos para problemas de ninja negro) – si No he encontrado la solución para entonces, mire la respuesta y entiéndala. Si no lo haces no mejorarás. Es importante pensar en los problemas por su cuenta, porque lo que importa 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 he vinculado) tiene todos los problemas de ninja en un capítulo aparte (Capítulo 22). Esto, en mi opinión, es una idea terrible. El libro que había tenido los problemas que se encuentran actualmente en el cap. 22 repartidos por todo el libro, cada uno en su capítulo correspondiente. Le sugiero que revise los problemas de 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 se ordenan en consecuencia (los problemas de ninja de Ch. 5 son lo primero, luego los de Ch. 6, etc.), así que esto no debería ser demasiado difícil, pero no estoy 100% seguro ya que tengo la copia más antigua del libro.
Nota 2: a veces pasaba horas en un solo problema, solo porque pensaba que el problema era realmente interesante e insistí en solucionarlo 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 requiere tiempo, por lo que es probable que no pueda hacer esto para todos los problemas, si es que desea hacerlo. en absoluto.
Días 14-24 – Etapa de codificación
Repite 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 resolvió el problema a ti mismo.) Esta es la etapa de codificación, así que no pierdas el tiempo volviendo a derivar algoritmos.
No sugiero que codifiques todos los problemas, especialmente si tienes experiencia con ACM-ICPC, TopCoder o Codeforces y similares (y realmente, si estás lo suficientemente familiarizado con STL, probablemente tengas un conjunto de habilidades decente). Solo escriba el código para los problemas que considere que tienen algoritmos complejos, una nueva estructura de datos que no ha usado antes (p. Ej., Un mapa desordenado para el hashing), problemas con casos complicados en las esquinas (la búsqueda binaria está en la parte superior de esta lista, ya que sus variantes son se le pregunta a menudo y puede ser mucho más complicado de lo que piensa) o un concepto de programación con el que no se sienta cómodo (esto incluye, pero no se limita a, sobrecarga de operadores, comparadores personalizados, funciones hash personalizadas, funciones personalizadas == y mucho más … ) Si un problema resulta complicado para usted, o si lo implementó de una manera que cree que no es óptima, mire las soluciones que ofrece el libro, que son excelentes y limpias, y le enseñarán todos los conceptos mencionados anteriormente. Te sugiero que imites un poco su estilo de escritura de código. Algunas notas importantes si son obvias son: use nombres de variables descriptivas (ninguna de esa mierda de nombre de variable de 1 letra) y guarde correctamente, y no se olvide de cerrar paréntesis y corchetes.
También te sugiero que codifiques todos los problemas del capítulo de Algoritmos codiciosos y casi todos los problemas marcados con ninja. El capítulo de Programación Dinámica también es importante si no está familiarizado con la DP, y puede ser difícil de entender, así que asegúrese de darle su tiempo.
Día 25 – Sobre más preguntas.
Así que ahora que ha agotado la mejor reserva de preguntas y se siente lo suficientemente cómodo como para ingresar a una entrevista, usted … necesita preparar aún más. Ir a preguntas de la entrevista de Google (Copa de carrera). Este es un lugar peligroso. Existen algunos problemas muy buenos, pero también hay una clase de problemas que a mi capacitador de ACM le gusta llamar “problemas de Chuck Norris”: problemas escritos en los que el OP no tiene idea de lo que está pasando y sugiere que el entrevistador requería un tiempo lineal para los 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 entrevistas de programación, debería poder diferenciar fácilmente entre problemas buenos y problemas terribles. En el día 25, revise “todas” (las últimas 20 páginas) las preguntas de Google (incluso si se está preparando para Facebook) y haga una lista de las que considere “buenas”, y por “buenas” quiero decir Los problemas que usted siente podrían haber sido preguntados 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 cuestionables. Supongo que debería tener una lista de algo así como 80-120 preguntas al final, algunas simples, otras no tanto.
También tenga en cuenta que muy pocos problemas tienen respuestas correctas publicadas en el sitio, así 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 demasiado 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 en el Día 25. Encuentra el algoritmo. Si sientes que es demasiado difícil, busca ayuda. Si sientes que es imposible o que la mejor solución es el tiempo exponencial, realmente podría ser que el OP se haya equivocado. Sacúdalo, pase a otro problema. Si aún te apetece, codifica algunos de los problemas más desafiantes.
Varias de las preguntas de la Copa de Carrera 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 para Google)
He escuchado que Google recientemente ha adquirido el hábito de 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, implementa y prueba tu propia Lista de Saltos. Hice esto solo para practicar y porque las Listas de Saltos son interesantes de todos modos.
Para ser honesto, Google puede ser bastante impredecible con sus preguntas a veces, en mi experiencia. Podrían 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 se haya olvidado de resolver, o en profundidad Preguntas sobre el lenguaje de programación (por ejemplo, sobrecarga de funtores / operadores en C ++). Supongo que depende de su currículum y de lo que dice ser competente, así que mi consejo es que no ponga nada allí en el que no sea al menos algo competente. Ayuda tener un título en Informática o Electricidad e Informática. Ingeniería, realmente, solo basada en la gran variedad en las posibles preguntas. Sugiero una lectura de Get that job en Google (Steve Yegge) y Five Essential Phone Screen Questions (Steve Yegge). Probablemente debería conocer la mayoría de los temas que se tratan aquí (no pondría mi dinero en temas como subprocesos / procesos / paralelismo a menos que lo indique explícitamente en su currículum, sin embargo). La mayoría de las preguntas de codificación en el segundo enlace son Creo que es demasiado fácil subir en una entrevista, así que no te emociones demasiado con ellos, y me saltearía la sección “Versión especial de vía rápida”. Es humorístico, pero pensé que era demasiado cínico y fuera de lugar. La elección del editor de texto, el conocimiento del sistema operativo o el conocimiento de uno contra varios idiomas no le harán fallar una entrevista, por sí solos.
En una pequeña nota, aunque creo que Google puede hacer muchas preguntas no algorítmicas como anteriormente, 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 saber, pero No son el foco principal.
Día 31 – Las cosas no técnicas
Bueno, estoy haciendo trampa un poco al agregar el Día 31, pero también deberías tomarte un día o más para prepararte para la parte no técnica de las entrevistas, especialmente si estás entrevistando en Facebook, donde hay una no técnica. entrevista. Primero, prepare las preguntas que quiera hacerles 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 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 solucionado, bugs difíciles con los que ha tenido que lidiar, etc. Búsqueda de Google “Preguntas de comportamiento” y encontrarás miles de preguntas posibles.
Prepare una respuesta no genérica para “Por qué Facebook” (sugerencia: ritmo acelerado y cultura, el gran talento de la empresa, la misión de conectar al mundo …) y “Por qué Google” (sugerencia: la diversidad de los esfuerzos, la 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 decepción, ya que me apasionaban ambas cosas y no podía esperar para demostrarlo), pero exprimí mi interés al hacer mis preguntas al entrevistador, así que aproveche esa oportunidad si realmente quieres impartir algo que no tuviste la oportunidad de hacer.
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 nerviosa antes de cada entrevista. Una vez que el entrevistador intervino y comenzamos a hablar, en general me divertí porque realmente me encantaba hablar con ellos y resolver este tipo de problemas. Haz tu mejor esfuerzo para no estar demasiado nervioso: haz entrevistas simuladas y cosas por el estilo. También recomiendo programar entrevistas en un orden de prioridad creciente, para que se acostumbre a ellas y descubra sus deficiencias en el momento en que llegue a su empresa más buscada.
- Practicar la codificación sin un compilador / en una pizarra / papel. No hice ninguno de los dos, pero tengo la sintaxis de C ++ memorizada y estoy acostumbrado a codificar en un artículo en competiciones de ACM, por lo que es posible que no tenga que hacer esto si ya está lo suficientemente cómodo con su idioma favorito (solo necesita saber un buen idioma, por cierto, siempre que sea razonablemente conocido, como C ++ / Java / Python. Le permiten usar el idioma que desee durante la entrevista.)
- Los casos de esquina pueden matarte. Realmente tienes que practicar para encontrar y tratar casos de esquina y / o reconocer lo que yo llamo “problemas propensos a los casos de esquina”. Algunos problemas son muy simples de forma algorítmica, pero pueden ser muy difíciles de codificar, y tuve 2 de estos problemas, una 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 cómo codificarlo, antes de hacerlo. 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 hubiera 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.
- Piensa en voz alta acerca de los algoritmos / ideas a medida que los creas. Está bien hacer una pausa y pensar en silencio por un momento, pero no te quedes allí durante 3 minutos sin decir una palabra. Siempre, al menos, dé la solución simple, que muy bien puede no tener un gran tiempo de ejecución, pero no le hará daño. Lo hice en todas mis entrevistas, no importa cuán simple sea la respuesta, pero las dije directamente y noté que probablemente haya una mejor solución, y luego pensé en eso. (Por ejemplo: está bien, para buscar una matriz ordenada, podemos escanearla de forma lineal, pero esta es una solución O (n) y probablemente haya algo más rápido). Además, no sea arrogante al respecto (pregúntese en voz alta hasta que esté seguro de su método y tenga una prueba aproximada de que su método funciona). No discutas con tu entrevistador. 99.99% del tiempo, tienen razón, y usted está equivocado. Una posible excepción a esto es si están desafiando tu código: o bien te están señalando un error o intentan hacer que parezca que es así para ver cuánta confianza tienes en tu código y si estás de acuerdo ciegamente o proteste de que 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 la punta # 4) mientras codifica. Sin embargo, menciona lo que estás haciendo en intrincadas líneas de código (por ejemplo, si quieres probar si ‘x’ es una potencia de 2 mediante “if (x & (x-1)) == 0”, es posible que desee mencionar eso.)
- Las preguntas son a menudo subespecificadas, y esta es una gran debilidad de los Elementos de las entrevistas de programación: todos los problemas se especifican completamente, por lo que casi no hay capacitación sobre esto. Siempre piense en las preguntas que podría hacer o en las condiciones que podrían hacer que su algoritmo falle si no es cierto. Algunos ejemplos son: ¿Todos los números son positivos? ¿Son distintos? ¿Cuál es el tipo de entrada (entero / doble …)? ¿Puedes volver a visitar una celda de cuadrícula? El libro tiene preguntas donde estas propiedades se especifican explícitamente en la pregunta: piense qué pasaría si estas condiciones no estuvieran allí: la solución a menudo se descompone.
- No te rindas si no piensas en la respuesta directamente. En mi última entrevista en Facebook, tuve el problema más difícil hasta el momento, y tardé unos 5 minutos en llegar a la respuesta, y terminé contratado. Esa fue en realidad 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 estados utilizando la Búsqueda en primer lugar para encontrar una secuencia más corta de “movimientos” (como este problema: ACM-ICPC Live Archive – Kermit the Frog ). Ambos salen muy a menudo.
- La suerte importa. El proceso de la entrevista no es perfecto, y es posible que no lo apruebes, incluso si eres realmente bueno, ya que depende de tus entrevistadores y de las preguntas que recibas (y del tipo de preguntas en las que estás convencido, etc.) mitigue mucho este factor preparando una gran cantidad, pero siempre está ahí, y es importante saberlo. Te sugiero que leas Get that job at Google (blog de Steve Yegge) si quieres más detalles sobre este factor.
- Ignorar ch. 20 y 21 en el libro. No son grandes (Tal vez lea el Capítulo 21 un poco para tener una idea, pero eso es todo.) Desplácese hacia abajo a la sección Diseño del sistema si también tiene que prepararse para una entrevista de diseño del sistema.
- Pónganse de relieve en su CV (o al menos, no se exageren), especialmente si lo solicitan a través de una referencia. Si escribe ‘experto en C ++’, llamarán a su ingeniero de C ++ más avanzado para que usted se caiga y se queme. Nunca he conocido a nadie que haya obtenido algo relacionado con multihilo y paralelismo en una entrevista para SWE, excepto una persona que lo mencionó como una habilidad. Y he aquí, se le preguntó al respecto y no le fue tan bien.
- A menudo, obtendrá un problema que es una variante de un problema que ha 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 aspecto). o una solución mayormente similar.) Tenga cuidado con estas diferencias sutiles; puede descubrir (o pensar que ya ha encontrado) la solución para el problema porque la encontró muy similar a una que ha visto antes, pero una pequeña diferencia en la declaración del problema significa que su solución es realmente 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 ello, 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 de bifurcación y no hay DP en absoluto involucrado. Si responde erróneamente a DP en lugar de derivar y viceversa o viceversa, el entrevistador sabrá que ha visto el otro problema antes y pensará que acaba de memorizar la solución, por lo que probablemente sea suficiente por sí solo para darle un “no “Contrato” por parte de ese entrevistador. (También me atrevería a suponer que el entrevistador no declararía esa afirmación en absoluto, exactamente por esta razón, y tendría que preguntar si puede visitar una entrada más de una vez, según la sugerencia). # 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.
Una vez más, 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 de Sistemas. Preparé visitando este sitio: Hired In Tech, que es decente (no excelente) y leyendo varios artículos 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 gordito. 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 de CAP, los temas de escalabilidad, y quizás lea sobre Hadoop y algunos problemas que puede resolver con él (Hadoop In Practice es un libro decente para estos propósitos). Pruebe algunas preguntas como la pregunta “Diseñar un acortador de URL” en Hired In Tech, o una escala mayor como “Diseñar un motor de búsqueda web” o “Diseñar Google Maps”, todas las preguntas que se pueden hacer (también consulte 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 muy buenas. Pero en general, para la entrevista de diseño de sistemas, practicar sobre preguntas es menos significativo que comprender los conceptos anteriores y saber cómo hacerlo. discútalas, ya que toda la entrevista es algo así como una conversación rápida entre usted y el entrevistador, donde cambiará las especificaciones de las preguntas sobre la marcha para ver cómo lidiar con diferentes escenarios.
Consejo final
Entonces, si realmente quieres ese trabajo, va a 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 bastante conocimiento de la preparación, y es probable que usted también lo haga.
Mi último consejo es simplemente ir a la entrevista y no estresarme (esto es obviamente más fácil decirlo que hacerlo). Los ingenieros quieren que seas bueno y que te contraten, la contratación es un proceso bastante costoso. Algunos pueden ser tranquilos, y otros pueden ser menos tolerantes, pero en todos los casos, la entrevista es muy similar a una conversación entre dos ingenieros, y eso es exactamente lo que estas compañías se esfuerzan por lograr en la entrevista, así que simplemente trátenla de esa manera. Si te has preparado bien, se mostrará.
[1] – Un capítulo por día es en realidad un poco lento ya que no está programando, así que para capítulos más cortos como los Capítulos 5, 7, 8, 9, le sugiero que haga 2 por día, lo cual es factible.
[2] – En Elementos de entrevistas de programación, los problemas que no son ninja son problemas estándar, los problemas de ninja gris son algo difíciles y los problemas de ninja negro son difíciles.
Descargo de responsabilidad: Esta es mi opinión / consejo, y no está respaldada por nadie de ninguna manera.