OO Diseño de preguntas relacionadas en entrevistas técnicas [cerrado]

He asistido a varias entrevistas recientemente y las compañías me han pedido que responda preguntas de "diseñar un [insertar modelo]" más de unas pocas veces.

1. ¿Es esto normal en la industria hoy en día? He estado en el mundo del software durante más de dos décadas y he asistido a mi parte de entrevistas, pero veo que este patrón en las entrevistas surgió recientemente.
2. Siento que la pregunta es muy abierta. Por ejemplo: me pidieron que dibujara un diagrama de clase para "Diseñar un estacionamiento". No estoy seguro de qué nivel de detalle espera el entrevistador. Esto fue en una prueba en línea donde se esperaba que adjunte un diagrama de visio, por lo que no podía preguntarles cuáles eran sus expectativas.
3. ¿Utiliza este tipo de preguntas en su proceso de entrevista? ¿Están relacionados solo con diagramas de clase o también pide secuencias, diagramas de flujo y ERD (por supuesto, según la naturaleza del puesto) ¿Han sido efectivos en su proceso de contratación?

* Editar para la respuesta de Kevin *

Por ejemplo: una pregunta completa podría ser "Diseñar un sistema de administración de estacionamiento que pueda usarse para encontrar espacios vacantes"

Me puede hacer con 2 clases, ParkingLoty Slot, o podría seguir para agregar IVehicley Vehicley Cary Motorcycleclases. ¿Dónde dibujo la línea?

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

1. Hasta cierto punto, sí. Cualquiera puede recitar la sintaxis o copiar / pegar a través de una solución. Queremos contratar personas que puedan resolver problemas.

2. Esperan que documente el diseño lo suficiente como para poder entenderlo (y no más que eso).

3. Le pregunto a la gente cómo resolverían el problema de XYZ, sí. Por lo general, solo lo describen verbalmente. Quiero ver si hacen preguntas para aclarar los requisitos. Quiero ver cómo se comunican con otros programadores. Quiero ver si pueden pensar de pie.

Me ha sido útil. No quiero monos de código, quiero ingenieros de software.

Encuentro estas preguntas bastante tontas. La verdadera respuesta es "¿cuáles son los casos de uso?" Sin un caso de uso, no hay necesidad de ningún diseño. Por ejemplo, aquí hay una respuesta perfectamente razonable a la pregunta del estacionamiento:

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

Satisface un caso de uso obvio.

De hecho, demuestra un uso de esta pregunta en su edición, donde no puede diseñar un modelo viable.

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

También mencionas crear Cary Motorcycleclases, lo que no tiene mucho sentido sin una mayor consideración. Su diseño no se va a beneficiar de haber subclasificado Vehicle. Si presentas Motorcyclesin ninguna diferencia de comportamiento Vehicle, lo consideraría un fracaso.

Si no detectaste el único Vehicleproblema, entonces casi estaríamos listos en una entrevista en vivo. Si corrigió eso (posiblemente haciendo eso a List<IVehicle>), usaría esto como punto de partida para ver la evolución de su diseño. Hay una razón por la cual los requisitos son básicos, y no hay casos de uso bien definidos: esa es la forma en que funciona el mundo.

Podría presentarle el nuevo requisito de que "dos motocicletas pueden estacionarse en una ranura" para ver cómo evolucionaría su diseño para manejarlo. Entonces, tal vez tengamos una conversación sobre la concurrencia (¿Qué pasa si tenemos dos entradas y dos autos se detienen simultáneamente? ¿Su diseño fallará? ¿Cómo? ¿Qué podemos hacer para solucionarlo?). Otras vías posibles para explorar serían cómo implementar el estacionamiento asignado, cobrar por el estacionamiento, las tarifas por fila (tal vez las filas más cercanas tienen que pagar más), el estacionamiento por tiempo limitado y cómo encontrar delincuentes, etc., etc.

También consideraría que su proceso de pensamiento alrededor de los estacionamientos es indicativo de su capacidad general para analizar un problema de manera inteligente. Si tiene que pedirme casos de uso básico y / o inventar otros extraños (como 2 por 1 especiales en estacionamiento), empiezo a preocuparme mucho de que nunca haya usado un estacionamiento antes y de que estamos Va a tener dificultades para comunicarse sobre algo un poco complicado.

Solía ​​preguntar esto: cuando creamos diagramas de clases para la generación de código. Todavía lo hago en ocasiones, pero no de manera rutinaria. Me gusta la pregunta porque me permite ver a la persona pensar.

Está destinado a ser abierto. Está bien. No hay una respuesta correcta. No tengo una respuesta en mi mente; Quiero ver a dónde lleva. Creo que es una mejor pregunta en persona, no "correo electrónico de respuesta". Se trata de comunicación, suposiciones e interacción; no solo una respuesta!

1. He visto este tipo de entrevistas al menos hace 12 años. Es el enfoque que he usado durante los últimos 6 años. La experiencia muestra que selecciona mejores candidatos para el trabajo que las 20 preguntas y les da una puntuación de 20 enfoques.

2. Una vez más, también lo haría muy abierto. El objetivo es proporcionar espacio para que el candidato demuestre habilidad. Tener un candidato que hizo preguntas relevantes en esta etapa sería una ventaja. Como es un candidato haciendo buenas suposiciones, pero señalando que eran suposiciones, y que necesitarían ser revisadas antes de la implementación.

3. Sí requiero que todos los empleados potenciales demuestren las habilidades que necesitan para el trabajo en la entrevista. Para los programadores, deberán implementar un código y hablar sobre su diseño para ello. Es muy efectivo para prevenir las malas contrataciones, pero prepárese para una tasa de fracaso del 90% en la entrevista.

Diseñar un sistema pequeño es en realidad un ejercicio muy relevante para preguntar en una entrevista. Muestra sus habilidades para encontrar una buena solución de software para un problema de dominio.

Sin embargo, me resulta extraño simplemente pedir publicar un diagrama de clase en línea sin interacción humana:

• Echarán de menos lo esencial: el razonamiento detrás del diagrama y lo que lo llevó a diseñar las cosas de esa manera.
• No hay "parapeto" para evitar que el solicitante vaya demasiado lejos. Si refleja una implementación final en el diagrama, probablemente tendrá docenas de clases y un esquema ilegible.
• Ser capaz de dibujar un diagrama de clase UML no es realmente una habilidad esencial, es solo una notación OO entre otras. La capacidad de crear diseños sólidos es.

En una entrevista en vivo, los pasos ideales que esperaría que tomara un candidato serían:

• Hable sobre el problema con el reclutador y comience a expresar una solución básica verbalmente, haciendo preguntas y ajustándose a medida que el reclutador brinde necesidades más precisas.
• Párate y dibuja una vista general del sistema y cómo los componentes podrían interactuar juntos. Podría ser el estilo más puro de UML, podrían ser solo cuadros y círculos.
• Escriba una prueba, ya sea prueba de aceptación de alto nivel o prueba de unidad para uno de los componentes / clases.
• Comience a escribir la implementación correspondiente.

Esperemos que en algún momento el reclutador haya reunido suficiente información sobre las habilidades del candidato y lo llame un día. El objetivo no es implementar una solución de trabajo completa (a menos que sea uno de estos servicios no remunerados en entrevistas encubiertas).

Las preguntas de OOP son abiertas. No hay una respuesta correcta o incorrecta, pero hay algunos principios que los entrevistadores esperan ver (como usar un constructor para inicializar variables, mantener sus métodos pequeños, usar encapsulación / composición / polimorfismo / herencia cuando corresponda, etc.).

Siempre espere preguntas relacionadas con la estructura de datos, OOP y la base de datos en las entrevistas, son muy comunes. Libros como "descifrar la entrevista de codificación" y "programar entrevistas expuestas" pueden ayudarlo a prepararse.

Me pidieron que hiciera un diseño para un estacionamiento no hace mucho tiempo. En primer lugar, no me dieron ningún caso de uso, pero lo mencioné un par más tarde. Creo que mi diseño no se ajustaba a lo que el entrevistador tenía en mente. Estoy de acuerdo en que cualquier diseño de software solo es válido para un caso de uso dado. Volviendo a esta pregunta de la entrevista, creo que mi entrevistador no tenía experiencia en diseño del mundo real. Esas personas creen que saben lo que piden. Es otra historia si eso es cierto o no.