Como faço para projetar um sistema arbitrário em uma entrevista? [fechadas]

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

Qual é a resposta esperada para essa 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?

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

• De cima para baixo - Olhando de baixo para cima, de um nível muito alto, crie um design e aprimore o design à medida que vários componentes são feitos, e aqui estão alguns dos componentes que eu pude ver ...

• Bottom-up - Olhando de baixo para cima, aqui estão alguns pedaços que se pode construir para tentar montar ...

• Esclarecimento dos requisitos - Fazendo perguntas sobre a escala projetada, tamanho, orçamento e equipe usados ​​para esse projeto. Você pode tentar codificar uma pessoa para um processador de texto muito simplificado ou planejar gastar centenas de milhões de dólares para criar o melhor sistema de gerenciamento de documentos que você acredita que é como o Google Doc levou ao extremo. Também aqui está a capacidade de perguntar algo como: "O que você quer dizer com Google Doc? Quanto dessa funcionalidade você deseja duplicar?" perguntas também.

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

Minha opinião pessoal seria que os projetos anteriores não são uma boa ideia aqui. O que se está tentando encontrar é 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 possa ser semelhante a algo do passado, pode haver diferenças suficientes para que a solução antiga não seja 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 bem diferente do exemplo inicial.

As entrevistas são uma via de mão dupla. Gerentes e outros desenvolvedores raramente são mestres em entrevistar, então não tenho certeza se vejo o valor em tentar afirmar que eles devem ser especialistas no assunto em entrevistas de emprego. Pude ver os recrutadores esperando saber como fazer uma entrevista, mas há muitos recrutadores ruins que podem ser usados ​​como exemplos de por que nem sempre é uma boa idéia.

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ê poderá realizar várias 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 no que você tende a se concentrar quando é apresentado um problema de design (Design de objeto? Tabelas SQL? Padrões de design?)
• Mostre ao chefe uma prévia de como será o desenvolvimento de um novo sistema com você, onde o chefe entra com uma especificação e diz: "O que seria necessário para construir isso?"

Esta pergunta é apenas uma versão de nível superior de "Descreva 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 dados a desenvolvedores juniores a intermediários. Nos desenvolvedores de nível inferior, o entrevistador pode avaliar o potencial de crescimento a longo prazo da pessoa na empresa, ou apenas ver o que ela faz quando enfrenta um grande problema que pode ser esmagador.

É 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, quais perguntas você faria, quais problemas você 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 do navegador etc. Como você dividiria a responsabilidade entre servidor e cliente? Como você lidaria com backups? O que acontece quando um servidor fica inoperante? O que você faria com documentos "abandonados" (coisas que não foram acessadas ou modificadas por um longo período de tempo)?

Novamente, o objetivo não é resolver nenhum desses problemas, mas identificá- los, conversar com eles, discutir um pouco sobre como resolvê-los, etc.

Sou uma das pessoas culpadas que frequentemente fazem esse tipo de pergunta em entrevistas. (Para constar, também faço perguntas semelhantes sobre o seu "projeto favorito".) A razão pela qual pergunto é que é algo que frequentemente fazemos por aqui. Temos engenheiros de design 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. Ficamos ao redor de um quadro branco e dizemos: "Ok, como vamos construir essa coisa?" Frequentemente, você sabe muito pouco sobre o novo recurso nesse ponto e só existe por causa de sua experiência em sua parte do sistema, mas ainda é esperado que você contribua de maneira produtiva. Não é apenas um exercício acadêmico hipotético.

Quanto ao tipo de resposta que eu espero, por exemplo, projetar um sistema para baixar novo firmware de um servidor, através de 20 placas de linha incorporadas em um escritório central para atualizar 5000 decodificadores no campo de uma só vez. Suponha que haja muito pouca capacidade disponível no link entre o servidor e as placas de linha.

Resposta ruim:

Eu provavelmente usaria Ethernet ou algo assim.

Boa resposta:

De que tamanho estamos falando? [Cerca de 7 MB.] Bem, você deseja garantir que o serviço não seja afetado durante o download. Você precisaria de flash ou RAM extra para armazenar duas imagens ao mesmo tempo. Você provavelmente desejaria armazenar em cache a imagem em suas placas de linha para evitar o download repetido da mesma imagem do servidor. Ao serem incorporadas, suas placas de linha provavelmente possuem uma CPU limitada; portanto, você pode precisar serializar os downloads para deixar capacidade suficiente para o serviço. Você gostaria de verificar se a imagem estava boa e voltar à versão antiga, se não funcionasse. Você precisaria de alguma maneira para tentar novamente algumas vezes e relatar erros a um humano se a atualização falhar. Se você tiver marcas diferentes de decodificadores, precisará de algum tipo de maneira de identificar qual imagem precisa enviá-la.

São quase transcrições palavra por palavra de dois candidatos diferentes. A maioria dos candidatos está no meio do caminho, mas geralmente chega lá no final com um pouco de alerta, o que é perfeitamente aceitável. Não estamos procurando o próximo Einstein aqui, apenas uma indicação de que você pode realmente raciocinar de maneira inteligente sobre os tipos de problemas em que trabalhamos todos os dias.

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

Um programador júnior não tem idéia 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 existem muitas facetas para o problema e tentará aprimorar um desafio. Você não precisa arquitetar todos os aspectos, basta identificar um desafio arquitetônico e descobrir como enfrentá-lo.

Considere a questão do Google Docs:

Uma coisa interessante é a escala de cisalhamento de solicitações que virão. Você não pode simplesmente obter um único servidor e implantar seu código nele - essa é uma tarefa maior. Um entrevistado bem-sucedido pode se concentrar nisso 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 possui estado, mas também compartilha 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 no UX. Talvez até discuta 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 Google Doc, porque existem consequências diferentes para que as coisas aconteçam em uma ordem diferente ou tenham uma estrutura ligeiramente diferente.

Não existe uma maneira única de criar um aplicativo como o Google Docs; você não precisa identificar o que faria a cada troca, mas é realmente ótimo encontrar uma área que tenha um problema interessante e explicar claramente qual é a troca. -offs pode ser.

-t.

Eu suspeito que o que os entrevistadores querem ouvir é:

O Google Doc é uma interface da web para um processador de texto. Os documentos do usuário são digitados e armazenados e podem ser recuperados pelo usuário no mesmo computador ou em um computador diferente.

O que você gostaria de discutir mais?

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

Para mim, se a pessoa não começar identificando os principais casos de uso / histórias, isso seria suficiente para saber que não está preparada para uma posição que exija essa habilidade específica.

Posteriormente, eles deverão conseguir uma solução arquitetural com base nos principais casos de uso / histórias. 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 solicitar um design mais detalhado, apenas 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 suspeito que, neste momento, estaríamos correndo contra uma barreira do tempo. Portanto, eu realmente não poderia penalizá-los por não considerarem esses problemas, porque há muito tempo e acho razoável que eles pensem que considerar todos os cenários possíveis não é esperado em uma situação de entrevista com tempo limitado.

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

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

Eu acho que uma coisa importante a fazer é fazer perguntas sobre os requisitos. Não faça apenas suposições que permitirão que sua solução de estimação funcione. Por exemplo, você pode conhecer algum método realmente bacana para imprimir documentos que pode ser tentado a descrever diretamente. Mas o Google Docs não imprime diretamente; produz um PDF que o cliente imprime. Portanto, se você começar com isso, gastará metade do seu tempo resolvendo um problema que não faz parte do problema e demonstrou que está mais interessado em usar sua tecnologia quente do que em resolver o problema do cliente.

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

Isso significa ler blogs, artigos, http://www.infoq.com , Hacker News, etc. Até o hardware blefe do Coding Horror.

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

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

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

E sim, procuro primeiro casos de uso, isso mostra que a pessoa está pensando. Em seguida, para multithreading, considere primeiro as estruturas de dados (aquelas que poderiam ser usadas para o problema, depois as mais apropriadas ou específicas com os porquês da decisão).

Esta é uma obrigação considerada para cargos de desenvolvimento sênior. É tolo e inútil para as pessoas sentar e responder a perguntas sobre implementações de classificação neste nível de experiência do desenvolvedor. O design do sistema é o que eu esperaria neste nível.