¿Cómo diseño un sistema arbitrario en una entrevista? [cerrado]

Una pregunta común en Tech Interview es diseñar un sistema particular, generalmente un producto existente de la empresa. Por ejemplo, "Diseñar Google Docs".

¿Cuál es la respuesta esperada para tal pregunta? Quiero decir, tales sistemas seguramente tienen un diseño complejo que está más allá del alcance de cualquier entrevista. ¿Qué esperan los entrevistadores en tan poco tiempo?

Información sobre cómo ve su cerebro este problema. Aquí hay algunos puntos de partida que pude ver sobre cómo se podría tratar de tener esta conversación:

• De arriba hacia abajo: mirando hacia abajo desde un nivel muy alto, desarrolle un diseño y desarrolle el diseño a medida que se realizan varios componentes y aquí hay un puñado de componentes que pude ver ...

• De abajo hacia arriba: desde cero, aquí hay partes que uno podría construir para tratar de armar ...

• Aclaración de requisitos: hacer preguntas sobre la escala proyectada, el tamaño, el presupuesto y el equipo utilizado para este diseño. Podría intentar que una persona codifique un procesador de texto muy simplificado o podría planear gastar cientos de millones de dólares para crear el mejor sistema de gestión de documentos que cree que es cómo Google Doc llevó al extremo. También aquí está la capacidad de preguntar algo como: "¿Qué quieres decir con Google Doc? ¿Qué parte de esa funcionalidad quieres duplicar?" preguntas también.

La clave es qué tan bien puede comunicar sus pensamientos y su enfoque para abordar este tipo de problema, ya que puede hacer que un usuario se acerque a usted y le pregunte: "Psst, ¿podría hacer algo como esto en 2 semanas?" eso realmente podría suceder. Por lo tanto, cómo dar la respuesta es más importante que cuál es la respuesta.

Mi opinión personal sería que los proyectos pasados ​​no son una buena idea aquí. Lo que uno está tratando de encontrar es qué tipo de creatividad y habilidades de comunicación en una nueva área en lugar de simplemente recordar cómo se hizo algo en el pasado. Lo más probable es que si bien algo que sucede en la nueva posición puede ser similar a algo del pasado, puede haber suficientes diferencias para que la solución anterior no sea factible. Es por eso que si bien lo que se puede construir es similar a una aplicación existente, puede haber varias personalizaciones que hacen que la solución sea bastante diferente del ejemplo inicial.

Las entrevistas son una calle de doble sentido. Los gerentes y otros desarrolladores rara vez dominan las entrevistas, así que no estoy seguro de ver el valor de tratar de afirmar que deberían ser expertos en la materia en las entrevistas de trabajo. Reclutadores que pude ver esperando saber cómo hacer una entrevista, pero hay muchos reclutadores pobres que podrían usarse como ejemplos de por qué esto no siempre es una buena idea.

Especialmente para los desarrolladores senior, creo que estas preguntas pueden ser muy buenas. Muestran que un desarrollador es capaz de pasar de una descripción grande y complicada a una implementación realista. Incluso con un sistema totalmente desconocido, debería poder realizar una serie de actividades interesantes para el entrevistador:

• Reúna los requisitos para responder la pregunta (por ejemplo, alcance)
• Divide el problema en partes más manejables; posiblemente identifique interfaces u objetos que puedan ser necesarios, o divida la lógica en front-end, back-end, DB, etc.
• Demostrar familiaridad con la estructura y los conceptos detrás de ese tipo de sistema, por ejemplo, aplicaciones web en el caso de Google Docs
• Muestre en qué tiende a enfocarse cuando se le presenta un problema de diseño (¿Diseño de objetos? ¿Tablas SQL? ¿Patrones de diseño?)
• Muestre al jefe una vista previa de cómo será desarrollar un nuevo sistema con usted, donde el jefe entra con una especificación y dice: "¿Qué se necesitaría para construir esto?"

Esta pregunta es solo una versión de nivel superior de "Describe la jerarquía de objetos que usarías para esto ...". "Describe la interfaz que diseñarías para esto ..." "Diseñe un conjunto de tablas de base de datos relacionales para estos datos ...", etc. En los desarrolladores de nivel inferior, el entrevistador podría estar evaluando el potencial a largo plazo de crecimiento de la persona en la empresa, o simplemente viendo lo que hacen cuando se enfrentan a un gran problema que podría ser abrumador.

Se trata de ver sus procesos de pensamiento en acción; no están interesados ​​en una solución, pero cómo abordarían la solución del problema, qué preguntas harían, qué problemas identificarían, etc.

Dado el ejemplo de Google Docs, los problemas obvios que vienen a la mente son cosas como el almacenamiento, la seguridad, la escalabilidad, la disponibilidad, el diseño de la interfaz del cliente, la compatibilidad del navegador, etc. ¿Cómo dividiría la responsabilidad entre el servidor y el cliente? ¿Cómo manejarías las copias de seguridad? ¿Qué sucede cuando un servidor se cae? ¿Qué haría con los documentos "abandonados" (cosas a las que no se ha accedido o modificado en un largo período de tiempo)?

Una vez más, el punto no es resolver ninguno de esos problemas, sino identificarlos , hablar sobre ellos, intercambiar ideas sobre cómo abordarlos, etc.

Soy uno de esos culpables que frecuentemente hacen este tipo de preguntas en entrevistas. (Para el registro, también hago preguntas similares sobre su "proyecto favorito"). La razón por la que pregunto es que es algo que hacemos con frecuencia por aquí. Tenemos ingenieros de diseño de todos los lados de una interfaz, alguien de ingeniería de sistemas, alguien de prueba y alguien con algún conocimiento de los casos de uso del cliente para la función. Nos paramos alrededor de una pizarra y decimos: "Bien, ¿cómo vamos a construir esta cosa?" A menudo, sabe muy poco acerca de la nueva característica en ese momento y solo está allí debido a su experiencia en su parte del sistema, pero aún se espera que contribuya de manera productiva. No es solo un ejercicio académico hipotético.

En cuanto a qué tipo de respuestas espero, tome, por ejemplo, el diseño de un sistema para descargar nuevo firmware de un servidor, a través de 20 tarjetas de línea integradas en una oficina central para actualizar 5000 decodificadores en el campo a la vez. Suponga que hay muy poca capacidad disponible en el enlace entre el servidor y las tarjetas de línea.

Mala respuesta:

Um, probablemente usaría Ethernet o algo así.

Buena respuesta:

¿De qué tamaño de imagen estamos hablando? [Alrededor de 7 MB.] Bueno, querrás asegurarte de que el servicio no se haya visto afectado durante la descarga. Necesitaría flash extra o RAM para almacenar dos imágenes a la vez. Probablemente desee almacenar en caché la imagen en sus tarjetas de línea para evitar descargar la misma imagen una y otra vez desde el servidor. Al estar incrustadas, sus tarjetas de línea probablemente tengan una CPU limitada, por lo que es posible que deba serializar las descargas para dejar suficiente capacidad para el servicio. Desearía alguna forma de verificar que la imagen fuera buena y volver a la versión anterior si no funcionara. Necesitaría alguna forma de volver a intentarlo varias veces e informar de errores a un humano si falla la actualización. Si tiene diferentes marcas de decodificadores, necesitaría algún tipo de forma de identificar qué imagen necesita enviar.

Esas son transcripciones casi palabra por palabra de dos candidatos diferentes. La mayoría de los candidatos se encuentran en un punto intermedio, pero generalmente llegan al final con una pequeña indicación, lo cual está perfectamente bien. No estamos buscando el próximo Einstein aquí, solo una indicación de que realmente puede razonar de manera inteligente sobre los tipos de problemas en los que trabajamos todos los días.

También hago este tipo de preguntas, y estoy de acuerdo con la mayoría de las otras respuestas. Tal vez ayudaría a los entrevistados a entender ¿POR QUÉ este tipo de pregunta es importante? Supongamos que tenemos que tomar una decisión comercial importante, y para hacerlo, necesitamos construir un nuevo sistema. Si alguien corre hacia ti y te pregunta qué se necesitaría para construir un sistema que tenga X, ¿puedes darles una respuesta perspicaz que prediga los principales desafíos y recursos necesarios?

Un programador junior no tiene idea de por dónde empezar. No están listos para comenzar a hablar sin una especificación detallada. Un programador senior verá instantáneamente que el problema tiene muchas facetas e intentará afinar un desafío. No tiene que diseñar cada aspecto, solo identificar un desafío arquitectónico y luego descubrir cómo abordarlo.

Considere el tema de Google Docs:

Una cosa interesante es la escala de corte de las solicitudes que llegarán. No puede obtener un solo servidor e implementar su código en él; esta es una tarea más grande. Un entrevistado exitoso podría enfocarse en esto y describirá los tipos de recursos que se necesitarán, y algunos de los desafíos técnicos para implementar a esa escala, con una aplicación que no solo tiene estado, sino que comparte el estado entre múltiples usuarios.

Otra cosa interesante sobre Google Docs es que varias personas pueden editar al mismo tiempo. Un entrevistado exitoso podrá discutir mecanismos para asegurarse de que el documento resultante no sea basura, y un candidato realmente excelente se dará cuenta de que los diferentes métodos de sincronización o fusión de ediciones tendrán un gran impacto en el rendimiento y la experiencia de usuario. Tal vez incluso debata las variaciones: un editor de documentos compartido para escribir código probablemente debería usar un método diferente para resolver conflictos que el típico Doc de Google, porque hay diferentes consecuencias de que las cosas sucedan en un orden diferente o que tengan una estructura ligeramente diferente.

No existe una única forma correcta de crear una aplicación como Google Docs, no tiene que identificar lo que haría para cada compensación, pero es realmente genial encontrar un área que tenga un problema interesante y explicar claramente cuál es el comercio -puedes ser.

-t.

Sospecho que lo que los entrevistadores quieren escuchar es:

Google Doc es una interfaz web para un procesador de textos. Los documentos de usuario se mecanografían y almacenan, y el usuario puede recuperarlos en la misma computadora o en una diferente.

¿Qué te gustaría discutir más?

Entonces, la pelota está en la cancha del entrevistador. Si quiere más detalles, puede preguntar. Lo que el entrevistador está buscando es, ¿puede mirar un problema o un producto y extraer el diseño?

Para mí, si la persona no comienza identificando los casos de uso / historias clave, eso sería suficiente para saber que no está preparada para un puesto que requiera esta habilidad en particular.

Posteriormente, deberían poder llegar a una solución arquitectónica basada en los casos de uso / historias clave. Esperemos que hayan utilizado algún proceso sistemático para identificar módulos además de sacarlos de su ... No esperaría mucho más de una situación de entrevista para la solución.

Sin embargo, podría elegir uno de los módulos arquitectónicos y pedir un diseño más detallado, solo para ver si tienen algunas habilidades de diseño. También sería bueno ver que consideran los casos de falla / problemas de rendimiento. Pero sospecho que en este punto, nos encontraríamos con un muro de tiempo. Por lo tanto, realmente no podría penalizarlos por no considerar estos temas porque solo hay mucho tiempo y creo que es razonable que asuman que no se espera tener en cuenta todos los escenarios posibles de una situación de entrevista de tiempo limitado.

Recientemente tuve una entrevista en la que me pidieron que diseñara un sistema de control de ascensor. Básicamente quieren ver tu enfoque de la tarea. Si le hacen esta pregunta, probablemente tengan un trabajo de muy alto nivel en mente para usted. Felicidades

La clave es cómo resolver problemas frente a los méritos de la solución que brinda, y si es capaz de lidiar con problemas generales.

Creo que una cosa importante es hacer preguntas sobre los requisitos. No solo haga suposiciones que permitirán que su solución para mascotas funcione. Por ejemplo, es posible que conozca algún método realmente ingenioso para imprimir documentos que puede verse tentado a saltar directamente a la descripción. Pero Google Docs no imprime directamente; produce un PDF que luego el cliente imprime. Entonces, si comienzas con eso, habrás desperdiciado la mitad de tu tiempo resolviendo un problema que no es parte del problema, y ​​habrás demostrado que estás más interesado en usar tu tecnología de punta que en resolver el problema del cliente.

Para manejar este tipo de preguntas de la entrevista, deberá tener un interés general en comprender "cómo funcionan las cosas", no solo en los proyectos que le interesan, sino también en los proyectos que siente que están muy alejados de sus experiencias.

Esto significa leer blogs, artículos, http://www.infoq.com , Hacker News, etc. Incluso los faroles de hardware de Coding Horror.

A pesar del hecho de que olvidará la mayor parte de lo que ha leído (porque esa información no está conectada de todos modos con su trabajo personalmente), puede haber algunos detalles que son las "semillas de la imaginación", y una pequeña fracción de esas semillas germinará cuando encuentre un problema similar en un futuro muy, muy lejano.

Entonces, el entrevistador tal vez esté interesado en su hábito de lectura (como parte de su pasatiempo) y vea si tiene un hábito regular de recolectar semillas de ideas de lugares aleatorios.

El punto detrás de hacer este tipo de preguntas es obtener una idea de su mente. Una pregunta común que uso es pedirles a los programadores que diseñen un sistema que pueda simular PacMan.

Y sí, primero busco casos de uso, me muestra que la persona está pensando. Luego, para el subprocesamiento múltiple, primero se consideran las estructuras de datos (las que podrían usarse para el problema, luego las más apropiadas o específicas con los por qué de la decisión).

Esta es una necesidad considerada para puestos de desarrollo superiores. Es tonto y sin sentido para las personas sentarse y responder preguntas sobre implementaciones de clasificación en este nivel de experiencia de desarrollador. El diseño del sistema es lo que esperaría a este nivel.