OO Design questões relacionadas em entrevistas técnicas [fechado]

Estive participando de muitas entrevistas recentemente e as empresas me pediram para responder às perguntas "criar um [inserir modelo]" mais de algumas vezes.

1. Isso é normal no setor hoje em dia? Estou no mundo do software há mais de duas décadas e participei de minha parte de entrevistas, mas estou vendo esse padrão nas entrevistas surgir apenas recentemente.
2. Eu sinto que a pergunta está muito aberta. Por exemplo: me pediram para desenhar um diagrama de classe para "Projetar um estacionamento". Não tenho certeza do nível de detalhe que o entrevistador espera. Isso foi realizado em um teste on-line, no qual era esperado que eu anexasse um diagrama visio, então não pude perguntar a eles quais eram suas expectativas.
3. Você usa esse tipo de perguntas no seu processo de entrevista? Eles são relacionados apenas a diagramas de classe ou você também pergunta a sequência, fluxogramas e ERDs (é claro, com base na natureza da posição) Eles foram eficazes no seu processo de contratação?

* Edite para a resposta de Kevin *

Por exemplo: Uma pergunta completa pode ser "Projetar um sistema de gerenciamento de estacionamento que possa ser usado para encontrar vagas disponíveis"

I pode ser feito com 2 classes, ParkingLote Slotou eu poderia continuar a adicionar IVehiclee Vehiclee Care Motorcycleclasses. Onde eu traço a linha?

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. Até certo ponto, sim. Qualquer pessoa pode recitar sintaxe ou copiar / colar o caminho através de uma solução. Queremos contratar pessoas que possam resolver problemas.

2. Eles esperam que você documente o design o suficiente para que eles possam entendê-lo (e não mais do que isso).

3. Pergunto às pessoas como elas resolveriam o problema XYZ, sim. Geralmente eles apenas descrevem isso verbalmente. Quero ver se eles fazem perguntas para esclarecer os requisitos. Eu quero ver como eles se comunicam com outros programadores. Eu quero ver se eles conseguem pensar de pé.

Tem sido útil para mim. Não quero macacos de código, quero engenheiros de software.

Acho essas perguntas um pouco tolas. A verdadeira resposta é "quais são os casos de uso?" Sem um caso de uso, não há necessidade de qualquer design. Por exemplo, aqui está uma resposta perfeitamente razoável para a pergunta do estacionamento:

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

Satisfaz um caso de uso óbvio.

Na verdade, você demonstra um uso dessa pergunta em sua edição, onde falha ao projetar um modelo viável.

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!??

Você também menciona criação Care Motorcycleclasses, o que não faz muito sentido sem mais considerações. Seu design não será beneficiado por ter subclassificado Vehicle. Se você apresentar Motorcyclesem diferenças de comportamento Vehicle, consideraria uma falha.

Se você não identificasse o único Vehicleproblema, seria praticamente feito em uma entrevista ao vivo. Se você corrigisse isso (possivelmente fazendo aquele a List<IVehicle>), eu usaria isso como ponto de partida para analisar a evolução do seu design. Há uma razão pela qual os requisitos são básicos e não há casos de uso bem definidos - é assim que o mundo funciona.

Eu poderia lhe oferecer o novo requisito de que "duas motocicletas podem estacionar em um slot" para ver como você desenvolveria seu projeto para lidar com isso. Talvez tenhamos uma conversa sobre concorrência (e se tivermos duas entradas e dois carros estacionarem simultaneamente - seu design falhará? Como? O que podemos fazer para consertá-lo?). Outras vias possíveis a serem exploradas seriam como implementar o estacionamento atribuído, cobrar pelo estacionamento, tarifas por fila (talvez as filas mais próximas tenham que pagar mais), estacionamento com tempo limitado e como encontrar criminosos, etc., etc.

Eu também consideraria seu processo de pensamento em torno dos estacionamentos como indicativo de sua capacidade geral de analisar um problema de maneira inteligente. Se você precisar me pedir casos de uso básicos e / ou inventar casos estranhos (como 2 por 1 especiais no estacionamento), começo a ficar muito preocupado com o fato de você nunca ter usado um estacionamento antes e de que estamos vai ter dificuldade em se comunicar sobre algo um pouco complicado.

Eu costumava perguntar isso quando criamos diagramas de classes para geração de código. Eu ainda faço de vez em quando, mas não rotineiramente. Gosto da pergunta porque me permite ver a pessoa pensar.

Destina-se a ser aberto em aberto. Isso está ok. Não existe uma resposta certa. Eu não tenho uma resposta em minha mente; Eu quero ver onde isso leva. Eu acho que é uma pergunta melhor para fazer pessoalmente, não "e-mail em resposta". É sobre comunicação, suposições e interação; não apenas uma resposta!

1. Eu já vi esse tipo de entrevista há pelo menos 12 anos. É a abordagem que tenho usado nos últimos 6 anos. A experiência mostra que ele seleciona melhores candidatos para o cargo do que as 20 perguntas feitas e atribui a elas uma pontuação entre as 20 abordagens.

2. Mais uma vez, eu também faria muito aberto. O objetivo é fornecer espaço para o candidato demonstrar capacidade. Ter um candidato que fizesse perguntas relevantes nesse estágio seria uma vantagem. Como é um candidato que faz boas suposições, mas sinaliza que elas são suposições e precisariam ser revisadas antes da implementação.

3. Solicito a todos os funcionários em potencial que demonstrem as habilidades necessárias para o trabalho na entrevista. Para os programadores, eles precisam implementar algum código e falar sobre seu design. É muito eficaz para evitar contratações ruins, mas esteja preparado para uma taxa de falha de 90% na entrevista.

Projetar um sistema pequeno é realmente um exercício muito relevante para perguntar em uma entrevista. Ele mostra suas habilidades em encontrar uma boa solução de software para um problema de domínio.

No entanto, acho estranho pedir apenas para postar um diagrama de classes on-line sem interação humana:

• Eles sentirão falta do essencial - o raciocínio por trás do diagrama e o que o levou a projetar as coisas dessa maneira.
• Não há "parapeito" para impedir o candidato de ir longe demais. Se você refletir uma implementação final no diagrama, provavelmente terá dezenas de classes e um esquema ilegível.
• Ser capaz de desenhar um diagrama de classes UML não é realmente uma habilidade essencial, é apenas uma notação OO entre outras. A capacidade de criar projetos sólidos é.

Em uma entrevista ao vivo, as etapas ideais que eu esperaria que um candidato adotasse seriam:

• Fale sobre o problema com o recrutador e comece a expressar uma solução básica verbalmente, fazendo perguntas e ajustando-o conforme o recrutador fornece necessidades mais precisas.
• Levante-se e esboce uma visão geral do sistema e como os componentes podem interagir juntos. Pode ser o estilo mais puro da UML, pode ser apenas caixas e círculos.
• Escreva um teste, teste de aceitação de alto nível ou teste de unidade para um dos componentes / classes.
• Comece a escrever a implementação correspondente.

Esperamos que, em algum momento, o recrutador tenha reunido informações suficientes sobre as habilidades do candidato e encerrado o dia. O objetivo não é implementar uma solução de trabalho completa (a menos que seja um desses serviços não pagos em entrevistas dissimuladas).

As perguntas OOP são abertas. Não existe resposta certa ou errada, mas existem alguns princípios que os entrevistadores esperam ver (como usar um construtor para inicializar variáveis, manter seus métodos pequenos, usar encapsulamento / composição / polimorfismo / herança quando aplicável, etc.).

Sempre espere perguntas relacionadas à estrutura de dados, POO e banco de dados em entrevistas, pois elas são muito comuns. Livros como "decifrar a entrevista de codificação" e "entrevistas de programação expostas" podem ajudá-lo a se preparar.

Me pediram para lançar um projeto para um estacionamento há pouco tempo. Não recebi nenhum caso de uso em primeiro lugar, mas mencionei alguns depois. Acredito que meu design não se encaixava no que o entrevistador tinha em mente. Concordo que qualquer design de software é válido apenas para um determinado caso de uso. De volta a esta pergunta da entrevista, acredito que meu entrevistador não teve nenhuma experiência em design do mundo real. Essas pessoas acreditam que sabem o que pedem. É outra história, se isso é verdade ou não.