¿Cuál es la mejor manera de responder, si se le pide diseñar, por ejemplo, un sistema de entrega de pizza? ¿Qué aspectos técnicos deben ser cubiertos?

Este tipo de preguntas sobre el diseño del sistema normalmente se formulan después de las primeras rondas cuando ha mostrado su estructura algorítmica / de datos y sus habilidades de programación, y el entrevistador está interesado en conocer su proceso de pensamiento mientras diseña un sistema desde cero.

Una entrevista con la que los candidatos a menudo luchan es la entrevista de diseño de sistemas. Incluso si conoce sus algoritmos y escribe código limpio, ese código necesita ejecutarse en una computadora en algún lugar, y entonces las cosas se complican rápidamente. Una cantidad realmente increíble de complejidad se encuentra debajo de algo tan simple como visitar Google en su navegador. Si bien la mayor parte de esa complejidad se abstrae del usuario final, como diseñador del sistema debe enfrentarlo directamente, y cuanto más pueda manejar, mejor.

Nominalmente, esta entrevista parece requerir conocimiento de los sistemas y un don para el diseño, y lo hace. Lo que lo hace interesante, y lo diferencia de una entrevista de codificación o algoritmos, es que cualquier solución que se te ocurra durante la entrevista es solo un efecto secundario. Lo que realmente le importa al entrevistador es el proceso. En otras palabras, la entrevista de diseño de sistemas tiene que ver con la comunicación .

ES UNA CONVERSACIÓN ABIERTA

Normalmente comenzará pidiéndole que diseñe un sistema que realice una tarea determinada. El aviso será simple, pero no se deje engañar: estos problemas son amplios y sin fondo, y el objetivo de la entrevista es ver cuánto volumen puede cubrir en 45 minutos.

En su mayor parte, dirigirás la conversación. Depende de usted entender el problema. Eso podría significar hacer preguntas, dibujar diagramas en la pizarra y rebotar ideas en su entrevistador. ¿Conoces las limitaciones? ¿Qué tipo de entradas necesita manejar su sistema? Debe tener una idea del alcance del problema antes de comenzar a explorar el espacio de posibles soluciones. Y recuerde, no hay una sola respuesta correcta para un problema del mundo real. Todo es una compensación.

Los sistemas son complejos, y cuando estás diseñando un sistema estás lidiando con su completa complejidad. Dado esto, hay muchos temas con los que debe estar familiarizado, como:

  • Concurrencia ¿Comprenden los hilos, el punto muerto y la inanición? ¿Sabes cómo paralelizar algoritmos? ¿Comprende la consistencia y la coherencia?
  • Redes . ¿Enteramente comprende IPC y TCP / IP? ¿Conoces la diferencia entre el rendimiento y la latencia, y cuando cada uno es el factor relevante?
  • Abstracción . Debes entender los sistemas en los que estás construyendo. ¿Sabe aproximadamente cómo funcionan un sistema operativo, un sistema de archivos y una base de datos? ¿Conoces los distintos niveles de almacenamiento en caché en un sistema operativo moderno?
  • Rendimiento en el mundo real . Debe estar familiarizado con la velocidad de todo lo que su computadora puede hacer, incluido el rendimiento relativo de la memoria RAM, disco, SSD y su red.
  • Estimación La estimación, especialmente en la forma de un cálculo inverso, es importante porque le ayuda a reducir la lista de posibles soluciones a solo las que son factibles. Entonces solo tienes unos pocos prototipos o micro-puntos de referencia para escribir.
  • Disponibilidad y Confiabilidad . ¿Estás pensando en cómo las cosas pueden fallar, especialmente en un entorno distribuido? ¿Sabes cómo diseñar un sistema para hacer frente a las fallas de la red? ¿Comprenden la durabilidad?

Recuerde, las personas no están buscando el dominio de todos estos temas. Están buscando familiaridad . Solo queremos asegurarnos de que tenga una buena disposición del terreno, para que sepa qué preguntas hacer y cuándo consultar a un experto.

Por lo tanto, no hay nada como la mejor manera posible de responder esas preguntas. Mantenga el diseño y la discusión al grano y trate de expresar sus pensamientos y todo lo que sabe. Pueden ser diagramas de clase para diagramar simples ER a la integración Frontend-Backend a complejos algoritmos de entrega y programación. Pero nunca empieces tomándolo como un problema de diseño de algo solamente.

Espero eso ayude.