Como eu projeto um sistema arbitrário em uma entrevista? [fechadas]

37

Uma pergunta comum na Tech Interview é projetar um sistema específico, geralmente um produto existente da empresa. Por exemplo, "Design Google Docs".

Qual é a resposta esperada para tal pergunta? Quero dizer, esses sistemas certamente têm um design complexo que está além do escopo de qualquer entrevista. O que os entrevistadores estão esperando em tão pouco tempo?

    
por Shamim Hafiz 10.05.2011 / 19:26
fonte

11 respostas

23

Perceba como o seu cérebro vê esse problema. Aqui estão alguns pontos de partida que eu poderia ver para como alguém poderia tentar ter essa conversa:

  • De cima para baixo - Olhando para baixo a partir de um nível muito alto, construa um design e desenvolva o design conforme vários componentes são feitos e aqui estão alguns componentes que eu pude ver ....

  • Bottom-up - Olhando de baixo para cima, aqui estão alguns pedaços que podem ser construídos para tentar montar ...

  • Esclarecimento de requisitos - Fazer perguntas sobre a escala, o tamanho, o orçamento e a equipe projetados para esse design. Você poderia tentar ter um código de pessoa um processador de texto muito simplificado ou você pode conspirar para gastar centenas de milhões de dólares para fazer o sistema de gerenciamento de documentos final que você acredita que é como você Google Doc levado ao extremo. Também aqui está a capacidade de perguntar algo como "O que você quer dizer com o Google Doc? Quanto dessa funcionalidade você deseja duplicar?" perguntas também.

A chave é quão bem você pode comunicar seus pensamentos e abordagem para lidar com esse tipo de problema, pois você pode ter uma abordagem do usuário e perguntar: "Psst, você poderia fazer algo assim em 2 semanas?" isso poderia realmente acontecer. Assim, como você dá a resposta é mais importante do que o que é a resposta.

Minha opinião pessoal seria de que projetos anteriores não são uma boa ideia aqui. O que se está tentando descobrir é que tipo de criatividade e habilidades de comunicação em uma nova área, em vez de apenas lembrar como algo foi feito no passado. As chances são de que, enquanto algo que acontece na nova posição pode ser semelhante a algo do passado, pode haver diferenças suficientes que a solução antiga não é viável. É por isso que, embora o que pode ser construído seja semelhante a um aplicativo existente, pode haver várias personalizações que tornam a solução bastante diferente do exemplo inicial.

Entrevistas são uma via de mão dupla. Gerentes e outros desenvolvedores raramente são mestres em entrevistas, então não tenho certeza se vejo o valor em tentar afirmar que eles devem ser especialistas no assunto em entrevistas de emprego. Recrutadores Eu poderia ver esperando saber como fazer uma entrevista, mas há uma abundância de recrutadores pobres que poderiam ser usados como exemplos de por que isso nem sempre é uma boa idéia.

    
por 10.05.2011 / 19:41
fonte
15

Especialmente para desenvolvedores seniores, acho que essas perguntas podem ser muito boas. Eles mostram que um desenvolvedor é capaz de passar de uma descrição grande e complicada para uma implementação realista. Mesmo com um sistema totalmente desconhecido, você deve ser capaz de fazer uma série de atividades interessantes para o entrevistador:

  • Reunir requisitos para responder à pergunta (por exemplo, escopo)
  • Divida o problema em partes mais gerenciáveis; possivelmente identifique interfaces ou objetos que possam ser necessários, ou quebre a lógica em front-end, back-end, banco de dados, etc.
  • Demonstrar familiaridade com a estrutura e os conceitos por trás desse tipo de sistema, por exemplo, aplicativos da Web no caso do Google Docs
  • Mostre em que você tende a se concentrar quando é apresentado a um problema de design (Design de objetos? Tabelas SQL? Padrões de design?)
  • Mostre ao chefe uma prévia de como será desenvolver um novo sistema com você, onde o chefe entra com uma especificação e diz: "O que seria necessário para construir isso?"

Esta questão é apenas uma versão de nível superior de "Descrever a hierarquia de objetos que você usaria para isso..." "Descreva a interface que você projetaria para isso ..." "Projete um conjunto de tabelas de banco de dados relacionais para esses dados ...", etc. que seriam fornecidos aos desenvolvedores de nível júnior a intermediário. Em desenvolvedores de nível mais baixo, o entrevistador pode estar avaliando o potencial de longo prazo da pessoa para o crescimento na empresa, ou apenas vendo o que ela faz quando se depara com um grande problema que pode ser esmagador.

    
por 10.05.2011 / 21:58
fonte
12

É sobre ver seus processos de pensamento em ação; eles não estão interessados em uma solução, mas como você abordaria a solução do problema, que perguntas você faria, quais problemas identificaria etc.

Dado o exemplo do Google Docs, os problemas óbvios que vêm à mente são: armazenamento, segurança, escalabilidade, disponibilidade, design da interface do cliente, compatibilidade com navegadores etc. Como você dividiria a responsabilidade entre o servidor e o cliente? Como você lidaria com backups? O que acontece quando um servidor fica inativo? O que você faria com documentos "abandonados" (coisas que não foram acessadas ou modificadas em um longo período de tempo)?

Mais uma vez, a questão não é resolver qualquer uma dessas questões, mas identificar elas, falar sobre elas, debater um pouco sobre como abordá-las, etc.

    
por 10.05.2011 / 20:22
fonte
9

Sou um desses culpados que freqüentemente fazem esse tipo de pergunta em entrevistas. (Para o registro, eu também faço perguntas semelhantes sobre o seu "projeto favorito".) A razão pela qual eu pergunto é que é algo que freqüentemente fazemos por aqui. Temos engenheiros de projeto de todos os lados de uma interface, alguém da engenharia de sistemas, alguém do teste e alguém com algum conhecimento dos casos de uso do cliente para o recurso. Estamos ao redor de um quadro branco e dizemos: "Tudo bem, como vamos construir essa coisa?" Muitas vezes você sabe muito pouco sobre o novo recurso nesse ponto e está lá apenas por causa de sua experiência em sua parte do sistema, mas espera-se que você contribua produtivamente. Não é apenas um exercício acadêmico hipotético.

Com relação ao tipo de respostas que espero, considere, por exemplo, projetar um sistema para fazer o download de um novo firmware de um servidor, através de 20 placas de linha incorporadas em um escritório central para atualizar 5000 caixas no campo de uma só vez. Suponha que há muito pouca capacidade disponível no link entre o servidor e as placas de linha.

Resposta incorreta:

Um, I would probably use ethernet or something like that.

Boa resposta:

How large an image are we talking about? [Around 7 MB.] Well, you'd want to make sure service wasn't affected during the download. You'd need extra flash or RAM to store two images at once. You'd probably want to cache the image on your line cards in order to avoid downloading the same image over and over from the server. Being embedded, your line cards probably have limited CPU themselves, so you might need to serialize the downloads in order to leave enough capacity for service. You'd want some way to verify the image was good and fall back to the old version if it didn't work. You'd need some way to retry a few times and report errors to a human if the upgrade fails. If you have different brands of set top boxes, you'd need some kind of way to identify which image you need to send it.

Essas são quase transcrições palavra por palavra de dois candidatos diferentes. A maioria dos candidatos está em algum lugar no meio, mas geralmente chega lá no final com um pequeno estímulo, o que é perfeitamente aceitável. Não estamos procurando o próximo Einstein aqui, apenas uma indicação de que você pode realmente raciocinar inteligentemente sobre os tipos de problemas em que trabalhamos todos os dias.

    
por 11.05.2011 / 00:27
fonte
5

Também faço esse tipo de pergunta e concordo com a maioria das outras respostas. Talvez ajudasse os entrevistados a entender PORQUE esse tipo de pergunta é importante? Suponha que tenhamos uma decisão comercial importante a ser tomada e, para isso, precisamos construir um novo sistema. Se alguém se aproximar de você e perguntar o que seria necessário para construir um sistema que faça X, você pode dar a eles uma resposta perspicaz que preveja os principais desafios e recursos necessários?

Um programador júnior não tem ideia de por onde começar. Eles não estão prontos para começar a falar sem uma especificação detalhada. Um programador sênior verá instantaneamente que há muitas facetas para o problema e tentará aprimorar um desafio. Você não precisa arquitetar todos os aspectos, apenas identificar um desafio arquitetônico e, em seguida, descobrir como resolvê-lo.

Considere o problema do Google Docs:

Uma coisa interessante é a escala de pedidos que virão. Você não pode simplesmente pegar um único servidor e implantar seu código nele - essa é uma tarefa maior. Um entrevistado bem-sucedido pode se concentrar nisto e descrever os tipos de recursos que serão necessários e alguns dos desafios técnicos na implementação nessa escala, com um aplicativo que não apenas tem estado, mas compartilha o estado entre vários usuários.

Outra coisa interessante sobre o Google Docs é que várias pessoas podem editar ao mesmo tempo. Um entrevistado bem-sucedido poderá discutir mecanismos para garantir que o documento resultante não seja lixo, e um candidato realmente ótimo perceberá que diferentes métodos de sincronização ou mesclagem de edições terão um grande impacto no desempenho e na experiência do usuário. Talvez até discutam variações: um editor de documentos compartilhado para escrever código provavelmente deve usar um método diferente de resolver conflitos do que o típico Documento Google, porque há diferentes consequências para as coisas que acontecem em uma ordem diferente ou com estrutura ligeiramente diferente.

Não há uma maneira única de criar um aplicativo como o Google Docs, você não precisa identificar o que faria para cada compromisso, mas é realmente ótimo encontrar uma área com um problema interessante e explicar claramente quais os trade-offs podem ser.

-t.

    
por 23.01.2015 / 02:18
fonte
2

Eu suspeito que o que os entrevistadores querem ouvir é:

Google Doc is a web interface for a word processor. User documents are typed and stored, and are retrievable by the user on the same or a different computer.

What would you like to discuss further?

Então, a bola está no campo do entrevistador. Se ela quiser mais detalhes, ela pode perguntar. O que o entrevistador está procurando é, você pode ver um problema ou um produto e extrair o design?

    
por 10.05.2011 / 19:34
fonte
2

Para mim, se a pessoa não começar a identificar os principais casos de uso / histórias, isso seria o suficiente para saber que eles não estão preparados para um cargo que exija essa habilidade em particular.

Depois, eles devem conseguir criar uma solução de arquitetura com base nos principais casos de uso / históricos. Espero que eles tenham usado algum processo sistemático para identificar outros módulos além de retirá-los de seus ... Eu não esperaria muito mais de uma situação de entrevista para a solução.

No entanto, posso escolher um dos módulos de arquitetura e pedir um design mais detalhado, só para ver se eles têm algumas habilidades de design. Também seria bom ver que eles consideram os casos de falha / problemas de desempenho. Mas eu suspeito que neste momento, estaríamos correndo em uma parede do tempo. Assim, eu realmente não poderia penalizá-los por não considerar esses problemas porque há muito tempo e eu acho que é razoável supor que, considerando todos os cenários possíveis, não é esperado de uma situação de entrevista limitada no tempo.

    
por 23.01.2015 / 19:02
fonte
1

Eu tive uma entrevista recentemente, onde me pediram para projetar um sistema de controle de elevador. Basicamente, eles querem ver sua abordagem para a tarefa. Se você está fazendo essa pergunta, eles provavelmente têm um trabalho de alto nível em mente para você. Parabéns.

    
por 10.05.2011 / 20:43
fonte
1

O principal é como você resolve os problemas versus os méritos da solução e se é capaz de lidar com problemas gerais.

Acho que uma coisa importante a fazer é fazer perguntas sobre os requisitos. Não faça apenas suposições que permitam que sua solução de animal de estimação funcione. Por exemplo, pode acontecer de você conhecer um método realmente interessante para imprimir documentos que você pode ser tentado a descrever corretamente. Mas o Google Docs não imprime diretamente. ele produz um PDF que o cliente então imprime. Então, se você começar com isso, terá esgotado metade do seu tempo resolvendo um problema que não faz parte do problema e demonstrado que está mais interessado em usar sua tecnologia mais quente do que em resolver o problema do cliente.

    
por 10.05.2011 / 20:59
fonte
0

Para lidar com esse tipo de perguntas da entrevista, você precisa ter um interesse geral em entender "como as coisas funcionam", não apenas em projetos nos quais você está interessado, mas também em projetos que você considera muito distantes de suas experiências. .

Isso significa ler blogs, artigos, link , Hacker News, etc. Até mesmo os bluffs de hardware do Coding Horror.

Apesar do fato de que você vai esquecer a maior parte do que leu (porque essas informações não estão conectadas ao seu trabalho pessoalmente), pode haver algumas informações que são as "sementes da imaginação" e uma pequena fração dessas sementes germinarão quando você encontrar um problema semelhante no futuro distante.

Assim, o entrevistador talvez esteja interessado em seu hábito de ler (como parte de seu hobby) e veja se você tem o hábito regular de coletar sementes de idéias de lugares aleatórios.

    
por 10.05.2011 / 21:43
fonte
0

O ponto por trás de fazer esse tipo de pergunta é obter uma visão da sua mente. Uma pergunta comum que uso é pedir aos programadores que projetem um sistema que possa simular o PacMan.

E sim, eu procuro primeiro os casos de uso, isso me mostra que a pessoa está pensando. Então, para multithreading, consideração de estruturas de dados primeiro (aquelas que poderiam ser usadas para o problema, então mais apropriadas ou específicas com os porquês da decisão).

Esta é uma obrigação considerada para cargos de desenvolvimento sênior. É bobo e sem sentido as pessoas se sentarem e responderem perguntas sobre implementações de classificação nesse nível de experiência do desenvolvedor. O design do sistema é o que eu esperaria neste nível.

    
por 27.04.2015 / 11:27
fonte

Tags