OO Preguntas relacionadas con el diseño en entrevistas técnicas [cerrado]

14

Recientemente he estado asistiendo a varias entrevistas y las empresas me han pedido que respondan las preguntas "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 surge 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 adjuntar 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 los diagramas de clase o también se preguntan secuencias, diagramas de flujo y ERD (por supuesto, según la naturaleza de la posición) 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 estacionamientos que pueda usarse para encontrar espacios vacantes"

Se puede hacer con 2 clases, ParkingLot y Slot o puedo continuar para agregar las clases IVehicle y Vehicle y Car y Motorcycle . ¿Dónde trazo 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; }
}
    
pregunta Nick 13.01.2013 - 02:25

8 respuestas

10
  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 usted documente el diseño lo suficiente como para que puedan entenderlo (y no más que eso).

  3. Le pregunto a la gente cómo resolverían el problema XYZ, sí. Usualmente 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 en sus pies.

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

    
respondido por el Telastyn 13.01.2013 - 02:59
6

Encuentro estas preguntas bastante tonto. 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.

    
respondido por el kevin cline 14.01.2013 - 06:44
5

En realidad, demuestras un uso de esta pregunta en tu edición, donde no puedes 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 la creación de las clases Car y Motorcycle , lo cual no tiene mucho sentido sin más consideración. Tu diseño no va a beneficiarse de tener subclasificado Vehicle . Si introduce Motorcycle sin diferencias de comportamiento en Vehicle , lo consideraría un error.

Si no detectó el problema de Vehicle , entonces lo haríamos en una entrevista en vivo. Si corrigieras eso (posiblemente haciendo que List<IVehicle> ), lo usaría como punto de partida para observar la evolución de tu diseño. Hay una razón por la que los requisitos son básicos, y no hay casos de uso bien definidos: así es como funciona el mundo.

Podría lanzarle el nuevo requisito de que "dos motocicletas pueden estacionarse en una ranura" para ver cómo evolucionaría su diseño para manejarlo. Entonces quizás 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 posibles vías para explorar serían cómo implementar el estacionamiento asignado, el cobro por estacionamiento, las tarifas por fila (quizás las filas más cercanas tengan 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 en torno a los estacionamientos es indicativo de su capacidad general para analizar un problema de manera inteligente. Si tiene que pedirme casos de uso básicos y / o idear casos extraños (como 2 por 1 especiales en el estacionamiento), empiezo a preocuparme de que nunca haya usado un estacionamiento antes y de que estamos va a tener dificultades para comunicarse sobre algo un poco complicado.

    
respondido por el Mark Brackett 03.02.2015 - 00:02
3

Solía preguntar esto: atrás cuando creamos diagramas de clase para la generación de código. Todavía lo hago en ocasiones, pero no de forma 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 mejor preguntar en persona, no "responder por correo electrónico". Se trata de comunicación, suposiciones e interacción; ¡No solo una respuesta!

    
respondido por el Jeanne Boyarsky 13.01.2013 - 03:43
3
  1. He visto este tipo de entrevistas hace al menos 12 años. Es el enfoque que he utilizado 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 puntos.

  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. Al igual que un candidato está haciendo buenas suposiciones, pero señalando que eran suposiciones y debería ser revisado antes de la implementación.

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

respondido por el Michael Shaw 13.01.2013 - 18:56
2

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

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

  • Se perderán lo esencial: el razonamiento detrás del diagrama y lo que te llevó a diseñar las cosas de esa manera.
  • No hay "parapeto" para impedir 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 verbalmente una solución básica, formule preguntas y realice ajustes a medida que el reclutador da necesidades más precisas.
  • Levántese y dibuje una vista general del sistema y cómo los componentes pueden interactuar entre sí. Podría ser el estilo más puro de UML, podría 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 convierta en un día. El objetivo no es implementar una solución de trabajo completa (a menos que sea uno de estos servicios no pagados en entrevistas de disfraces).

    
respondido por el guillaume31 04.02.2014 - 15:31
0

Las preguntas de la POO 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 base de datos en las entrevistas, son muy comunes. Los libros como "descifrar la entrevista de codificación" y "entrevistas de programación expuestas" pueden ayudarlo a prepararse.

    
respondido por el sakisk 13.01.2013 - 15:53
-1

Hace poco me pidieron que presentara un diseño para un estacionamiento. No me dieron ningún caso de uso en primer lugar, pero 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 determinado. Volviendo a esta pregunta de la entrevista, creo que mi entrevistador no tenía ninguna experiencia de diseño en el mundo real. Esas personas creen que saben lo que piden. Es otra historia si eso es cierto o no.

    
respondido por el vw98 04.02.2014 - 05:29

Lea otras preguntas en las etiquetas