Entrevista de Crack the System Design: consejos de un ingeniero de software de Twitter

Recientemente escribí sobre cómo obtuve ofertas de varias empresas de tecnología de primer nivel. Durante el proceso de preparación de mi entrevista, leí mucho material y preparé un conjunto de notas sobre cómo abordar los problemas de diseño del sistema. En este artículo, me gustaría compartir esos consejos con todos ustedes.

Si es un recién graduado sin experiencia en sistemas distribuidos a gran escala, o incluso un ingeniero experimentado con años de experiencia en su haber, este artículo será útil para usted.

Actualización (24/3/2019) : si desea unirse a un grupo de estudiantes para aprender más sobre el diseño de sistemas, ¡estoy organizando una clase pequeña juntos! Puede ir a este enlace para obtener más información o visitar mi sitio web: zhiachong.com para obtener más información.

Este artículo se divide en las siguientes cuatro secciones:

  • Haga preguntas aclaratorias
  • Usa tu fondo
  • Abordar un problema de forma sistemática
  • Mantenga sus propias notas

Haga preguntas aclaratorias

Un objetivo central de una entrevista de diseño de sistemas es brindar al candidato la oportunidad de demostrar sus conocimientos.

No hay respuestas estrictamente correctas o incorrectas. Una buena pregunta sobre el diseño de un sistema suele parecer muy ambigua, y la razón de ello es que se supone que le da la oportunidad de demostrar lo siguiente:

  • ¿Cómo pensarías sobre el espacio problemático?
  • ¿Cómo piensas sobre los cuellos de botella?
  • Qué puede hacer para eliminar estos cuellos de botella.

Imagina que te piden que diseñes una caja negra. ¿Cómo abordaría el problema? No hay instrucciones claras sobre lo que necesita construir aquí, aparte de que la caja puede contener algunos elementos dentro de ella.

Una de las estrategias más útiles que empleo personalmente es hacer preguntas aclaratorias. ¿Cuáles son las preguntas de aclaración "buenas", preguntas?

Una buena pregunta aclaratoria lo ayuda a lograr una o más de varias cosas:

  1. Le ayuda a reducir el alcance de lo que se supone que debe hacer
  2. Ayuda a aclarar cuáles son las expectativas del usuario del sistema.
  3. Le da instrucciones sobre dónde proceder
  4. Le informa de posibles cuellos de botella / áreas problemáticas

En el ejemplo de la caja negra, podría preguntar, “bueno, ¿qué contiene la caja? ¿Cuántos artículos contiene? ¿Y quién es el usuario previsto? "

A eso, podría decir, construyamos una caja amarilla con un emoticón que debería contener como máximo 1 pelota de tenis. Sin embargo, esta no es una pelota de tenis común. Tendrá al menos 0,5 m de radio y pesará alrededor de 1 kg. Está hecho para abrazarlo, no para abrazarlo, así que no quiero ningún control sobre él.

Ahí tienes, esta es la caja.

Siempre haga preguntas aclaratorias. No se le juzga por si hizo o no una pregunta específica durante la entrevista, pero sí por cómo piensa sobre el espacio del problema.

Por ejemplo, si te pidiera que diseñaras Twitter ahora mismo, ¿cómo lo harías? Tómate unos minutos para pensar en ello y tal vez incluso esbozarlo en una hoja de papel. Vaya tan profundo y ampliamente como pueda, y luego vuelva a este artículo. Mejor aún, puede dejar sus notas en los comentarios a continuación y podemos discutir más.

Si aún no se ha dado cuenta, el resultado final del ejercicio anterior arrojaría resultados significativamente diferentes. Para mi propia experiencia específica, podría profundizar mucho en el diseño de API y la infraestructura de backend. Probablemente también exploraría problemas específicos de iPhone, debido a mi experiencia. Hablaré sobre cómo el cliente interactúa con los puntos finales de nivel medio, cómo funcionaría el registro, cómo diseñaría el backend para garantizar el tiempo de actividad, etc.

Estas son discusiones bastante interesantes que puede tener con un colega, y esa es una señal muy fuerte que está buscando un entrevistador.

Usa tu experiencia a tu favor

A menudo veo a ingenieros tratando de averiguar qué está tratando de preguntar el entrevistador y luego ajustando sus respuestas a las expectativas.

De hecho, desaliento a cualquiera de hacer esto por varias razones:

  1. Todo el mundo tiene una experiencia única. En una entrevista de diseño de sistemas, es una oportunidad para que demuestre cuáles son sus fortalezas. No pierda la oportunidad tratando de averiguar qué podría esperar otra persona de usted.
  2. El entrevistador puede haber estado asintiendo con la cabeza a lo largo de sus respuestas, pero es posible que haya sabido que solo está engañando y no pensando en el problema.

Su experiencia y antecedentes pueden variar mucho del próximo candidato. Aportas un conjunto de valores y experiencia a la mesa que nadie más puede. Eso es lo que te hace valioso e insustituible. Independientemente del campo en el que se encuentre, a la gente le importa lo que pueda aportar.

Abordar el problema de forma sistemática

Ahora, con mi experiencia en mente, hay varias cosas en las que pienso cuando estoy abordando un nuevo sistema. Le recomiendo encarecidamente que también formule un conjunto de criterios o pasos para usted.

Algunas de las cosas en mi mente cuando trabajo en un nuevo sistema son:

  • ¿Cuál es el objetivo del sistema?
  • ¿Quiénes son los usuarios del sistema?
  • ¿Cuál es la escala con la que estamos trabajando?
  • ¿Es este un sistema nuevo / antiguo? ¿Cómo manejamos el control de versiones?

Entre otros…

Mira, mi conjunto de criterios será diferente del conjunto de criterios de un ingeniero de front-end. Utilizo estos criterios para formular una imagen en mi cabeza, y estos guiarán mi proceso de toma de decisiones.

Armado con respuestas a esas preguntas, puedo comenzar a abordar el problema en cuestión y luego dividirlo sistemáticamente en componentes individuales.

Un buen ejercicio que me gusta hacer es cómo diseñar un sistema de pedido de café . Un día pensé en esto mientras estaba sentado en Starbucks, y me di cuenta de que sería bueno si pudiera pedir un batido en mi teléfono y recogerlo en mi Starbucks local.

Mi mente comenzó a ir en varias direcciones:

  • ¿Qué hace esta máquina para pedir café?
  • Si construyo uno, ¿puedo venderlo a Starbucks, o lo etiqueto en blanco y lo vendo como un servicio?
  • ¿Cuántos usuarios necesito apoyar si lo vendo a Starbucks?
  • Alternativamente, si le doy una etiqueta blanca, ¿puedo vender la interfaz a mi servicio de pedidos de café y luego ayudar a los clientes a construir un backend para que puedan almacenar los pedidos en sus máquinas locales?

Una vez que obtengo respuestas a estas preguntas, finalmente puedo formarme una imagen completa de lo que hace mi servicio de pedidos de café. Así es como se vería mi versión del servicio de pedido de café:

Mi servicio de pedido de café es un software como servicio (SAAS). Ofrece una interfaz para que se conecten varios socios.

  • Tiene una API, llamada addCoffeeForMerchant , que inserta el nombre del café, el precio del café y los ingredientes del café.
  • Tiene una API GET, llamada getCoffeesForMerchant , que devuelve una lista de cafés para un ID de comerciante determinado.
  • El ID de comerciante es un identificador único (UUID) que se genera mediante algún mecanismo de hash, que se puede aclarar aún más con el cliente.
  • El software está optimizado para operaciones de solo lectura, porque la mayoría de mis clientes crean su menú una vez y lo leen varias veces durante el día.
  • Tiene un mecanismo de almacenamiento en caché que utiliza la estrategia de desalojo de uso menos reciente (LRU), porque si el elemento del menú no se ha pedido por un tiempo, a mi cliente no le importa si tarda un poco más en aparecer en el menú.
  • En caso de que uno de los almacenes de datos entre en erupción, mi servicio de pedidos de café replicará los datos en diferentes clústeres en el oeste de EE. UU. Y la costa este de EE. UU. Porque me dirijo al mercado de EE. UU. Solo por ahora.

Alternativamente, cualquier otro servicio de pedido de café que pueda imaginar también sería muy probable. Es solo una cuestión de para qué está optimizando. Creo que estos son problemas muy interesantes y es un gran ejercicio mental para mantener la mente ocupada.

Mantenga sus propias notas

Como ingeniero de software, es un proceso de aprendizaje sin fin. Te recomiendo que uses Evernote o Moleskin para tomar notas. Personalmente llevo un pequeño cuaderno para las ideas rápidas que necesito anotar, y guardo varias otras cosas en Evernote siempre que puedo.

Tengo un cuaderno llamado "Programación" en mi Evernote. Siempre que me encuentro con algo nuevo o interesante, lo anoto en mi cuaderno para futuras referencias.

Reviso y asigno etiquetas a estas nuevas notas de forma mensual o trimestral para asegurarme de que las notas estén organizadas. Por ejemplo, tengo una etiqueta de "Diseño" para todo lo que tenga que ver con el diseño del sistema. Podría ser algo así como un enlace a un video de YouTube que encontré interesante, o un argumento interesante que presentó mi compañero de trabajo en el que no había pensado.

Esta es una muestra de cómo se ve una de mis notas:

Una de las cosas que aprendí recientemente de un compañero de trabajo es que NoSQL es excelente para la creación de prototipos, porque no es necesario someterse a discusiones de esquema con otros equipos. Si quisiera cambiar el esquema, puedo hacerlo muy rápido con una base de datos NoSQL. Ese fue un aprendizaje clave del trabajo que inserté en mi cuaderno de “Programación”.

Divido mis notas en:

  1. Diseños de sistemas
  2. Entrevistas (experiencia + revisión de diferentes entrevistas que he tenido en el pasado, agrupadas por nombre de empresa)
  3. Tid-bits aleatorios, CS es bueno saber, como útiles scripts de bash o trucos de línea de comandos
  4. Lecturas / videos de YouTube

Todas las notas anteriores se encuentran en "Programación". Con el tiempo, descubro que tengo una colección pseudoorganizada de cosas que he leído o explorado en el pasado.

Como cualquiera que me conozca a nivel personal, no soy una persona muy organizada. Por lo tanto, solo he recopilado quizás entre el 10 y el 15% de las cosas, por lo que queda mucho más por hacer allí.

El conocimiento y la práctica van de la mano para mejorar en el diseño de sistemas. Si cree que su trabajo actual no le brinda la oportunidad de hacer diseños de sistemas, entonces debería encontrar uno que sí lo haga o intentar diseñar una pequeña parte de una arquitectura existente de manera que sea más rápida, más barata, más robusta, o más fácil de modificar en el futuro.

Recursos que recomiendo

Introducción a: Arquitectura y diseños de sistemas: gran tutorial de Youtube de un ex ingeniero de Facebook sobre cómo abordar los problemas de diseño de sistemas.

Diseño de aplicaciones con uso intensivo de datos: otro buen recurso para aprender a diseñar para escalar. Habla de varias cosas que un ingeniero de software típico da por sentado: cómo funcionan las bases de datos (mySQL y noSQL), cuándo usar cada una, ventajas y desventajas de varias técnicas para manejar la escala, etc. ¿Lo recomiendo ampliamente?

Entrevistas simuladas: un entorno simulado que imita la entrevista real es extremadamente útil para prepararse para las entrevistas. Si puedes encontrar un amigo que lo haga por ti, te lo recomiendo. También realizo entrevistas simuladas, así que si estás interesado, ¡no dudes en contactarme en zhiachong.com!

Lo que todo ingeniero de software debería saber sobre la abstracción unificadora de datos en tiempo real: una discusión técnica muy extensa sobre registros y compensaciones. Aún no lo he terminado, pero me lo recomendó un compañero de trabajo.

Evernote: ¿el mejor? aplicación de mantenimiento de notas que he usado. Hay muchos tutoriales sobre cómo utilizar mejor Evernote. No los he revisado todavía, simplemente porque lo uso como un cuaderno. Allí registro todo lo que aprendo y, de vez en cuando, lo reviso y lo reorganizo.

Cuaderno Moleskin - Realmente disfruto este. La calidad de la misma es extremadamente alta. El precio es un poco más alto, pero como lo uso a diario, lo considero una buena inversión. Tener un hermoso cuaderno en mis manos todos los días me emociona más para escribir más notas.

Pilot G2 (negro): fácilmente los mejores bolígrafos que he usado y los únicos que usaré. Los compro a granel en Amazon y los guardo dondequiera que voy. Tengo uno en mi mochila, uno en la oficina y otro en la oficina de mi casa para tener siempre un bolígrafo a mano. Escribe muy bien, la tinta fluye sin problemas y me encanta la sensación de escribir con ella. Junto con el Moleskin, a veces solo quiero tomar el G2 para anotar cosas al azar porque estos dos son tan perfectos juntos.

Entrevista sobre Grokking the System Design: esta es una recomendación de amigos. Es un curso en línea que enseña cómo diseñar un sistema distribuido en detalle. Sin embargo, es un curso de $ 79. Hay un precio de equipo. Si hay algún interés, consultaré con ellos para ver si es posible formar un grupo para el descuento grupal.

Sígueme en Twitter, Facebook y LinkedIn. Regístrese en mi lista de correo, donde regularmente envío consejos, trucos y conocimientos de la industria.

Si disfrutó de este artículo, comente a continuación: ¿cuál es su consejo para construir un sistema escalable y confiable?