¿Cómo NO diseñar Netflix en su entrevista de diseño de sistema de 45 minutos?

En los últimos dos años, he ayudado a más de 100 ingenieros a prepararse para entrevistas en empresas de tecnología. El año pasado, también me ofrecí como voluntario para realizar entrevistas simuladas para recién graduados. Antes de fundar mi startup, entrevisté a cientos de candidatos en Facebook y Microsoft. Durante estas discusiones, fue obvio que los candidatos están más nerviosos por las entrevistas de diseño del sistema que por las entrevistas de codificación. También noté un patrón recurrente de errores que cometen muchos candidatos. En este post, voy a identificar algunos de esos errores. ( ). Planeo escribir más sobre lo que DEBE hacer durante sus entrevistas, pero si está buscando recursos para prepararse, mencioné algunos recursos al final de esta publicación Nosotros, los ingenieros, tememos las entrevistas de diseño de sistemas porque no podemos diseñar grandes sistemas durante los proyectos escolares e incluso durante nuestros trabajos, rara vez tenemos la oportunidad de crear un sistema escalable desde cero. Por lo general, nos unimos a un equipo establecido y tenemos la tarea de escribir funciones para un componente específico. Pasamos la mayor parte de nuestro tiempo corrigiendo errores, optimizando código y escribiendo pruebas. Sin embargo, cuando se le pide que diseñe un sistema distribuido a gran escala en 45 minutos, no desea perder tiempo discutiendo cómo puede reducir 20 milisegundos el tiempo de respuesta al evitar una copia de búfer. En su lugar, debe identificar los componentes de alto nivel y describir cómo estos componentes interactuarán entre sí. ¿Puedes siquiera diseñar Netflix en 45 minutos? Por lo general, se le pide que diseñe Netflix (u otro servicio escalable con cientos de millones de usuarios) en 45 minutos. Es una pregunta aparentemente absurda. 45 minutos es demasiado poco incluso para discutir los detalles de cualquier componente. Estos servicios han sido desarrollados por cientos o miles de ingenieros a lo largo de muchos años. ¿Cómo puedes comprimir todo ese trabajo y dibujarlo en una pizarra de 5x5? La clave aquí es entender lo que está buscando su entrevistador. Quiere que le brinde una descripción general de 50,000 pies, identifique los componentes de alto nivel y describa las interacciones entre los componentes de la manera más sucinta posible. Aquí hay 3 fases de tal discusión. Dibuja un cuadro grande que represente el sistema. Acérquese y divida esa caja grande en 5 o 6 componentes. Analice brevemente la función de cada componente, por ejemplo, cómputo, almacenamiento, front-end, back-end, almacenamiento en caché, colas, redes, equilibrio de carga, etc. Su entrevistador querría que discuta 1 o 2 componentes con más profundidad y él especificará cuál. Rara vez se espera que escriba código durante estas discusiones. Aquí hay algunos errores comunes que los candidatos cometen durante sus entrevistas. Sé 20 palabras de moda, así que debería estar bien. Podrías estar pensando, si tengo que diseñar en un nivel abstracto, probablemente pueda hacer tonterías a mi manera durante la entrevista de diseño. No tan rapido. Su entrevistador está buscando compañeros de equipo con los que trabajará todos los días, y alguien que está tratando de decir tonterías durante la entrevista lo hará una y otra vez. Cualquier entrevistador experimentado estará atento a las personas que intentan lanzar palabras de moda como "No-SQL", "Mongo DB" y "Hadoop". Siempre, siempre espere que su entrevistador le pida más detalles y justificación. Solo use palabras de moda y tecnologías de moda, por ejemplo, "GraphQL", si las comprende bien y puede justificar y defender su enfoque. Regla 1: leer High Scalability una noche antes de su entrevista no lo convierte en un experto en sistemas distribuidos. Puedo pretender ser un experto He escuchado las historias de varias situaciones muy vergonzosas en las que el candidato pretendía ser un experto en algo solo para darse cuenta de que el entrevistador es el conocido experto de la industria en dicho campo. Además de las historias anteriores (que no contaré aquí), yo mismo he estado en tales situaciones varias veces, en ambos lados de la mesa. En 2006, Microsoft me entrevistó y mi entrevistador me preguntó si había implementado B-Trees (o quizás B+ Trees). Le dije que sé lo que son los B-Trees y que son útiles en las bases de datos pero que no puedo recordar nada más. Pasó a otros temas. Más tarde supe que mi entrevistador era James Hamilton, un destacado experto en bases de datos y sistemas distribuidos. Avance rápido unos años, pude implementar árboles B+ (árboles B+ grandes que contienen TB de datos) para Azure Storage de Microsoft, y ahora sé un par de cosas sobre los árboles B+. Incluso hoy, me daría miedo decirle a James Hamilton que sé lo que es un árbol B+. En el otro lado de la mesa, una vez un entrevistado me dijo que había implementado ciertas características en un código base determinado. Desconocido para él era el hecho de que solía trabajar en esa base de código antes de que se uniera a ese equipo. Investigué un poco y me di cuenta de que solo implementó un cliente para ese código base, pero reclamaba mucho más. Los incidentes como el anterior son obviamente raros. Mucho más probables son dos cosas: Su entrevistador podría estar trabajando en las tecnologías de las que está hablando y puede distinguir fácilmente entre un impostor y un experto. Probablemente ha hecho esta pregunta 1000 veces y conoce bien las posibles soluciones. Rápidamente descubrirá cuánto entiendes realmente. Regla 2: Nunca pretendas ser un experto. La persona que te entrevista casi siempre entiende el dominio mejor que tú e incluso puede ser un experto en la industria. Este es realmente mi dominio. terminaré en 15 minutos Bien por ti, pero más despacio. En lugar de saltar a la solución que ya conoce, haga lo siguiente: Reunir requisitos. Hacer preguntas. Su entrevistador está interesado en comprender sus procesos de pensamiento. Evalúe múltiples soluciones, discuta los pros y los contras y vea a dónde lo lleva la discusión. En realidad, es una buena idea hacer esto ya sea que conozca el dominio o no. Regla 3: No se apresure a encontrar una solución. Reúna requisitos, sugiera múltiples soluciones y evalúelas. Está destinado a ser una discusión abierta. Bono: no seas ese chico (Descargo de responsabilidad: lo que sigue es una conversación hipotética y cualquier parecido con personas reales o eventos reales es pura coincidencia). Implementemos Twitter. ¿Cómo vas a almacenar todos los tweets? Voy a usar una base de datos NoSQL como MongoDB. Entrevistador: Candidato: ¿Por qué no MySQL? RDBMS no escala. Necesitamos una base de datos escalable como MongoDB o BigTable. Entrevistador: Candidato: Pero nosotros en Twitter almacenamos todos nuestros tweets en MySQL, y escala muy bien. Bueno, entonces estoy corregido. Tal vez su escala no es tan grande. Los servicios que necesitan más escala, como Facebook, usan soluciones NO-SQL. Entrevistador: Candidato: Pero Facebook también usa MySQL. No sé cómo pueden escalar. Tendré que buscarlo. Tal vez tengan un MySQL en el front-end respaldado por BigTable. Entrevistador: Candidato: No importa. ¿Dónde debemos almacenar nuestros datos analíticos? Obviamente en MySQL. Entrevistador: Candidato: Pero es demasiado para MySQL. Lo almacenamos en HDFS. Probablemente comenzó a crear Twitter antes de que MongoDB madurara. MongoDB puede manejar fácilmente tanto sus tweets como sus datos analíticos. Entrevistador: Candidato: Muy bien, gracias por su tiempo. Fue genial hablar contigo. Entrevistador: Recursos para prepararse para entrevistas de ingeniería de software Si está buscando un recurso para prepararse para las entrevistas de diseño de sistemas, consulte el curso recientemente lanzado que cubre los conceptos básicos de los sistemas distribuidos y tiene lecciones interactivas que cubren cómo diseñar Instagram, Dropbox, Twitter, Facebook Messenger, Youtube , búsqueda de publicaciones en Facebook, escritura anticipada, rastreadores web, Yelp y Uber/Lyft. Grokking the System Design Interview Si se está preparando para entrevistas de codificación, eche un vistazo a . Tiene más de 80 problemas con código en , , , y . Cada problema tiene visualizaciones interactivas para explicar cada paso para que realmente entiendas las soluciones en lugar de solo memorizarlas. Coderust 2.0: Preparación de entrevistas de codificación más rápida mediante visualizaciones Python Java Javascript C++ Ruby ¿Crees que estás listo pero necesitas algo de práctica? Programe una . entrevista simulada Fahim es el co-fundador de Educativa . Estamos construyendo la plataforma de aprendizaje de próxima generación para ingenieros de software e instructores. Los estudiantes aprenden pasando por un curso interactivo. Los instructores pueden crear y publicar cursos interactivos utilizando nuestro creador de cursos. Si está interesado en publicar cursos o saber más, no dude en comunicarse. Si te gustó esta publicación, haz clic en el signo del corazón a continuación y sígueme para ver más publicaciones.