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

Recientemente escribí sobre cómo conseguí ofertas de múltiples compañías tecnológicas 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/03/2019): si desea unirse a un grupo de estudiantes para obtener más información sobre el diseño del sistema, ¡organizaré una pequeña clase 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.

Cómo diseñar el sistema: consejos de un ingeniero de software de Twitter

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

  • Hacer preguntas de aclaración
  • Usa tu fondo
  • Abordar un problema sistemáticamente
  • Guarda tus propias notas

Hacer preguntas de aclaración

Un objetivo central de una entrevista de diseño de sistemas es darle al candidato la oportunidad de demostrar su conocimiento.

No hay respuestas estrictamente correctas o incorrectas. Una buena pregunta de diseño del sistema por lo general suena muy ambigua, y la razón es que se supone que te dará 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.
Cómo diseñar esta caja negra

Imagine que se le pide que diseñe una caja negra. ¿Cómo abordarías 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 de aclaración. ¿Qué preguntas de aclaración son "buenas", preguntas?

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

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

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

A eso podría decir, construyamos una caja amarilla con una carita sonriente que debería contener como máximo 1 pelota de tenis. Sin embargo, esta no es una pelota de tenis ordinaria. Tendrá un radio de al menos 0,5 m y pesará aproximadamente 1 kg. Está destinado a ser abrazado, no abrazado, por lo que no quiero que lo manejen.

Ahí tienes, esta es la caja.

Mi caja ideal con una cara sonriente

Siempre haga preguntas de aclaración. No se lo juzga por si formuló o no una pregunta específica durante la entrevista, pero se le juzga por cómo piensa sobre el espacio del problema.

Por ejemplo, si te pidiera que diseñaras Twitter en este momento, ¿cómo lo harías? Tómese unos minutos para pensarlo, 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 a fondo.

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 back-end. Probablemente también exploraría problemas específicos de iPhone, debido a mi experiencia. Hablaré sobre cómo interactúa el cliente con los puntos finales de nivel medio, cómo funcionaría el registro, cómo diseñaría el back-end 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 fondo para tu ventaja

Muchas veces veo ingenieros que intentan averiguar qué está tratando de preguntar el entrevistador y luego responden a sus respuestas para que se ajusten a las expectativas.

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

  1. Todos tienen un fondo único. En una entrevista de diseño de sistemas, es una oportunidad para que demuestre cuáles son sus puntos fuertes. No desperdicies la oportunidad tratando de descubrir lo que alguien más puede esperar de ti.
  2. Es posible que el entrevistador haya estado asintiendo con la cabeza a sus respuestas, pero podrían haber sabido que simplemente se está abriendo camino y no está pensando realmente en el problema.

Su experiencia y antecedentes pueden variar ampliamente del próximo candidato. Trae 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, las personas se preocupan por lo que puede aportar.

Abordar el problema sistemáticamente

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

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 / viejo? ¿Cómo manejamos las versiones?

Entre otros…

Verá, mi conjunto de criterios será diferente del conjunto de criterios de un ingeniero 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 pedidos de café. Pensé en esto mientras estaba sentado en Starbucks un día, 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 ordenar café?
  • Si construyo uno, ¿puedo venderlo a Starbucks o lo etiqueto en blanco y lo vendo como un servicio?
  • ¿Cuántos usuarios necesito admitir si lo vendo a Starbucks?
  • Alternativamente, si lo etiqueto en blanco, ¿puedo vender la interfaz a mi servicio de pedidos de café y luego ayudar a los clientes a construir un back-end para que puedan almacenar los pedidos en sus máquinas locales?
Cómo abordar este problema

Una vez que obtengo respuestas a estas preguntas, finalmente puedo formar 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 pedidos de café:

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

  • 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 una ID de comerciante determinada.
  • La identificación del comerciante es un identificador único (UUID) que se genera utilizando algún mecanismo de hash, que se puede aclarar 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 ordenado por un tiempo, a mi cliente no le importa si aparece un poco más lento 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 grupos en todo el oeste de EE. UU. Y la costa este de EE. UU. Porque solo estoy apuntando al mercado estadounidense por ahora.

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

Guarda tus propias notas

Como ingeniero de software, es un proceso interminable de aprendizaje. Le recomiendo que use Evernote o Moleskin para guardar notas. Personalmente llevo una pequeña libreta para 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. Cada vez que me encuentro con algo nuevo, o algo interesante, lo apunto en mi cuaderno para más referencias.

Reviso y asigno etiquetas a estas nuevas notas mensualmente o trimestralmente 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 mi compañero de trabajo expuso y que no había pensado.

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

Perdón por la mala gramática y errores tipográficos: p

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 hay necesidad de someterse a discusiones de esquemas con otros equipos. Si quisiera cambiar el esquema, puedo hacerlo realmente rápido con una base de datos NoSQL. Ese fue un aprendizaje clave del trabajo que inserté en mi cuaderno de "Programación".

Desgloso 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 bueno para saber, como scripts de bash útiles o trucos de línea de comandos
  4. Lecturas / videos de YouTube

Todas las notas anteriores van bajo "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 recolectado entre el 10 y el 15% de las cosas, por lo que aún queda mucho por hacer.

El conocimiento y la práctica van de la mano para mejorar los diseños de sistemas. Si cree que su trabajo actual no le brinda la oportunidad de hacer diseños de sistemas, entonces debe 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 intensivas en datos: otro buen recurso para aprender a diseñar para escalar. Habla sobre 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, los pros y los contras de varias técnicas para manejar la escala, etc. Lo recomiendo encarecidamente

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

Lo que todo ingeniero de software debe saber sobre la abstracción unificadora de datos en tiempo real: una discusión muy extensa y técnica sobre registros, compensaciones. Todavía no lo he terminado, pero es muy recomendable por parte de un compañero de trabajo.

Evernote: la mejor aplicación para guardar notas que he usado. Hay muchos tutoriales sobre cómo utilizar mejor Evernote. Todavía no los he revisado, simplemente porque lo uso como un cuaderno. Registro todo lo que aprendo allí, y luego ocasionalmente los reviso y los reorganizo.

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

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

Grokking the System Design Interview: 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 descuentos grupales.

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

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