¿Es razonable esperar que un desarrollador senior sepa cuáles son los patrones de diseño de OOP? [cerrado]

Estoy preparando preguntas para entrevistas de trabajo para un puesto de desarrollo senior. El trabajo incluiría un diseño orientado a objetos, y el software existente usa patrones de diseño, por lo que me gustaría pedirles a los candidatos que expliquen algunos patrones de diseño que conocen, han usado, cómo los han usado, por qué lo han hecho. los usó y así sucesivamente. Sin embargo, en entrevistas anteriores cuando le pregunté a desarrolladores senior con al menos 5-10 años de experiencia sobre patrones de diseño, casi nadie había oído hablar de ellos. Creo que dos de cada veinte desarrolladores podrían nombrar un patrón de diseño único (Singleton y MVC, respectivamente).

Entonces mi pregunta es: ¿tiene sentido hacer estas preguntas? ¿O es este un tema tan oscuro que no puede esperar que los nuevos empleados ya los conozcan?

¿Debería un desarrollador senior tener experiencia previa con patrones de diseño, o diría que los patrones de diseño son un tema tan simple que cada desarrollador decente puede elegirlos durante el entrenamiento? Si es así, ¿qué preguntas haría para evaluar sus habilidades de diseño?

Agregar Después de leer las respuestas hasta ahora, debo dar algunas aclaraciones:

• El trabajo es para un desarrollador .NET con experiencia en OOP / OOD
• El código existente usa nombres de clase como IParameterGraphVisitory IStorageFactoryen muchos lugares
• ¿Cómo le preguntas a la gente sobre sus experiencias pasadas con los diseños OO que crearon, si no tienen el vocabulario para explicar sus diseños? Eso es lo que quiero hacer, y todo lo que se me ocurre es "dibuje la jerarquía de diseño / objeto de su último proyecto en la pizarra".

Lo más probable es que lo hacen conocerlos. Puede que simplemente no los conozcan como "patrones de diseño"; es decir, pueden no estar familiarizados con la terminología académica para tales cosas. Lo que ves como una 'máquina de estado' podría ser simplemente un enfoque de sentido común para un problema a un programador más viejo y experimentado. Nunca presté mucha atención a los 'patrones de diseño', por ejemplo, pero cuando supe qué era una máquina de estado, tuve que reírme porque lo había estado haciendo durante años. ¿Quién sabía que era tan académico? Siempre lo consideré una habilidad básica de codificación, y no un "patrón de diseño".

El punto no es asumir que sus desarrolladores experimentados conozcan los términos del libro de texto para las cosas; en cambio, pregúnteles cómo estructurarían las clases o cómo abordarían una tarea.

Su expectativa es bastante razonable para un desarrollador senior de OO. Cualquiera que se llame a sí mismo que, sin conocer los Patrones de diseño, simplemente demuestra que la experiencia no se obtiene automáticamente con el paso de los años :-( Seguro que hay muchos desarrolladores por ahí que han pasado años o incluso décadas en el campo, sin haber escuchado sobre el diseño patrones: eso solo muestra que no estaban interesados ​​en aprender nuevas ideas, mejorarse y adoptar las mejores prácticas.

¿Debería un desarrollador senior tener experiencia previa con patrones de diseño, o diría que los patrones de diseño son un tema tan simple que cada desarrollador decente puede elegirlos durante el entrenamiento?

La experiencia de la OMI cuenta mucho. En teoría, un desarrollador decente puede leer Patrones de diseño en un libro, o incluso en Wikipedia, y comprender el concepto básico en 15 minutos. Sin embargo, aplicar los conceptos correctamente requiere una experiencia duramente ganada. Es fácil enamorarse de los patrones, tratando de incluirlos en cada código posible, l'art pour l'art. También es fácil descartarlos diciendo que "los patrones no son una bala de plata, solo usa la cosa más simple que podría funcionar". Encontrar el punto medio entre los dos extremos aprendiendo cuándo y cómo usar patrones para resolver problemas reales, y cuándo no usarlos, lleva años de experiencia .

¿Qué preguntas harías para evaluar sus habilidades de diseño?

En concierto con lo anterior, solo agregaría estas preguntas a su lista:

• ¿Cuáles son los inconvenientes de los patrones de diseño (en general, y de los que mencionan explícitamente)?
• ¿Cuándo no usarlos y por qué?

Actualizar

@GrandmasterB tiene un buen punto porque algunos desarrolladores pueden estar usando patrones de diseño específicos sin saber su nombre. En cierto modo tiene razón en que esta es una cuestión de terminología / comunicación. Sin embargo, la otra cara de la moneda es que, de hecho, es una cuestión de terminología / comunicación :-) Es decir, uno de los principales beneficios de Design Patterns es dar un vocabulario común a los desarrolladores, mejorando enormemente la comunicación . (¡Trate de explicar la idea básica de Adaptador sin usar la palabra en sí misma, o sus sinónimos "wrapper" y otros!) Por lo tanto, por muy talentoso e informado que sea un candidato, sin conocer la terminología (s) ampliamente aceptada, introducirá un problema de comunicación en tu equipo

¿Un desarrollador senior ? Seguro. Un junior debería. Tengo 15 años, no tengo educación formal sobre el tema e incluso yo los entiendo. No solo es razonable esperar que los conozcan, sería inaceptable si no lo hicieran. Suponiendo que sepan algo sobre programación orientada a objetos, es muy probable que lo sepan.

En una entrevista, debe preguntar qué es fundamental que el candidato sepa para hacer el trabajo.

Si tienen que conocer los nombres de los patrones como son de Gang of Four, entonces ese es un requisito válido.

Si, por otro lado, desea que muestren un conocimiento práctico adecuado de la arquitectura del programa, creo que es mejor que les dé un problema y les pregunte cómo estructuraría el código. Si le dan la solución de patrón adecuada, entonces tiene pruebas de que lo saben, independientemente del nombre utilizado.

Cada vez que entrevisto para puestos de alto nivel, tienden a ser más "prácticos" que las preguntas y respuestas. Quiero una demostración clara de habilidad y comodidad en la programación. También quiero una base firme en los conceptos de CS, lo que significa habilidades más generales de cómo aplicar conceptos como encapsulación, algoritmos, acoplamiento / cohesión, etc. Experiencia y familiaridad en múltiples lenguajes y paradigmas.

Depende del área de su experiencia. No esperaría que un desarrollador de C incorporado supiera mucho sobre patrones de diseño. Si hablamos de un desarrollador de Java o .NET, deben estar familiarizados con los patrones de diseño y, especialmente, con cómo no dejarse llevar por ellos.

Asumiendo que estás buscando antigüedad en OOP, la respuesta es definitivamente sí. Los patrones de diseño son léxico del lenguaje OOP.

Además, hoy en día no es razonable que un programador decente de OOP con 10 años de experiencia no pueda nombrar un patrón de diseño, siendo patrones de diseño ampliamente adoptados en API estándar, bibliotecas y marcos de desarrollo.

Hace años que he estado haciendo esta pregunta durante las entrevistas y es una sorpresa cuando el candidato no proporciona respuestas satisfactorias sobre el tema.

Sí, pero probablemente debería obtener su comprensión haciendo preguntas de diseño en lugar de pedirle a la gente que enumere los patrones de diseño de los que han oído hablar. Me siento bastante cómodo con los patrones descritos en PoEAA, GoF e incluso algunos patrones de programación funcionales y todavía no creo que aprendas mucho más sobre mi enfoque para resolver problemas al pedirme que nombre algunos patrones.

Dada una pregunta como "diseñarme un editor de texto" con seguimientos como "¿Cómo vas a admitir objetos incrustados como imágenes? ¿Negrita y cursiva? ¿Deshacer?" Es probable que eventualmente escuche lo suficiente como para reconocer el patrón de comando, el patrón compuesto, el patrón de recuerdo y algunos otros incluso con una breve conversación.

Los patrones de diseño se descubrieron y luego se describieron para tener un lenguaje común con el cual comunicar las decisiones de diseño.

Desafortunadamente, he trabajado para alguien para quien cada uso de un patrón de diseño tenía que explicarse y justificarse, no por la debida diligencia, sino porque simplemente no los conocía. Eso no es divertido. Pero los desarrolladores más serios, por accidente o diseño, han aprendido los nombres de los patrones OO más comúnmente utilizados, por lo menos, y la mayoría de los desarrolladores de aplicaciones empresariales que valen la pena al menos saben algo sobre los patrones PoEAA más comunes.

Razonable. Definitivamente Necesario. No

Pregunto a los posibles candidatos si conocen los patrones de diseño. Es solo uno de varios criterios para ser considerado en su conjunto. No pase por alto la imagen total.

Sí, muchos desarrolladores, sin saberlo, usan algunos patrones de diseño, sin duda.

No es por eso que hago la pregunta.

Es importante saber que puedo comunicarme de manera rápida y efectiva con otro desarrollador. No quiero pasar 20 minutos en una pizarra explicando una máquina de estado solo para descubrir que "la usaron antes, pero nunca supieron cómo llamarla". Esto no es productivo.

También ayudan en el proceso de refactorización. Echar un vistazo a través del código uno podría implementar al azar algún tipo de patrón de fábrica, pero el patrón de fábrica de GoF ha resistido la prueba del tiempo. Es por eso que es el patrón de fábrica, no TODAVÍA fp (no es preferible reinventar la rueda, Joel en el software tiene muchas desventajas de hacerlo).

Un equipo que usa y reconoce la importancia de los patrones de diseño aumenta la comunicación y la productividad. Si su equipo, como unidad, no usa dp, entonces pierden su relevancia.

Hablando desde mi propia experiencia, ignoré los patrones de diseño durante bastante tiempo. Sabía que existían, pero nunca leí sobre ellos. Una vez que finalmente mordí la bala, me di cuenta de que había estado usando patrones de diseño todo el tiempo y simplemente no me di cuenta o no sabía que mis soluciones de diseño en realidad tenían un nombre común.

Me inclinaría más a plantear un conjunto de problemas en los que un patrón de diseño particular se ajusta bien a la solución y ver que el desarrollador presenta algo similar al patrón. Si lo hacen, genial. Podría estar aún más inclinado a contratar a un desarrollador que utilizara patrones de diseño sin saberlo, ya que veo que muchos desarrolladores que tienen conocimiento de patrones de diseño intentan adaptar una solución a un patrón cuando no es apropiado en lugar de darse cuenta de que un patrón en particular sucede para resolver el problema. problema bien

Creo que una mejor pregunta sería: dado un nombre de un patrón y una descripción del patrón, por ejemplo, un patrón de fábrica del libro Gang of Four, el candidato debería ser capaz de llegar a un escenario en el que el patrón sería Un enfoque razonable.

Hay desarrolladores con 5-10 años de experiencia y hay desarrolladores senior. No son lo mismo en absoluto. Sí, si está contratando a un nivel superior y espera que las personas conozcan y usen patrones de diseño, entonces no contrataría a una persona mayor que no estuviera familiarizada con ellos. Eso sería como contratar a un especialista en bases de datos que no entendía las uniones izquierdas. Eso es bastante básico para un verdadero desarrollador senior. Sin embargo, probablemente contrataría a una persona menor.

Sí, de hecho, deberían estar familiarizados con el término e incluso deberían poder nombrar algunos de los patrones, pero no cometan el error de confundir el conocimiento teórico con la experiencia.

Hay muchas personas que antes de una entrevista repasarán los patrones de diseño, y pueden decirlos brevemente con una breve descripción, pero esa es solo la teoría. Es un desarrollador senior real que puede detectar cuándo usar uno, o sin el conocimiento de un patrón formal resolvería el problema en una forma de patrón de diseño clásico.

La mejor manera de verificar es dejar que diseñen algo frente a usted y hacer preguntas de sondeo ... un desarrollador sénior es alguien que puede pensar naturalmente en el nivel de abstracción. Estas son las personas que "crean" los patrones de diseño.

Al igual que la clase Peopleware que habla de contratar a un malabarista sin pedirles que hagan malabarismos, solo porque dicen que pueden no significa mucho ... pruébalos.

Como ya se dijo, también creo que está bien si no recuerdan las palabras de moda de memoria. Pero dado que esta es una posición de alto nivel, deben saber cuándo aplicar un patrón para resolver un problema de manera óptima en lugar de utilizar las peores soluciones. Por lo tanto, denles un problema que debería resolverse utilizando un patrón (por ejemplo, cómo crear un objeto sin codificar su clase, cómo acceder a los elementos de un objeto sin tener detalles sobre su implementación, etc.) y ver cómo Lo atacarán.

Definitivamente deberían conocer los patrones, pero no necesariamente las palabras de moda.

Por ejemplo, MVC tiene muchas alternativas muy similares como PAC, 3 niveles. Hace unos años, otra palabra de moda popular para MVC fue "Modelo 2". De hecho, conozco muy buenos desarrolladores que conocen perfectamente ese patrón, pero no sabían que la palabra de moda actual es MVC.

Muy simple: si los está utilizando, debe preguntar a sus candidatos. Si conocen patrones, entonces debería agregar algunos puntos positivos; pero no saberlo no necesariamente debe excluirlos, especialmente si muestran buenas habilidades de OOD. Es poco probable que los desarrolladores que han estado en proyectos de mantenimiento sepan mucho sobre los patrones de diseño en comparación con aquellos que han estado interesados ​​en diseñarlos. también depende de si se les ha enseñado patrones de diseño en la universidad. En mi experiencia, es poco probable que lo hagan. La mayoría de las universidades y cursos privados te enseñan OOP pero no OOD. Las posibilidades de que hayan estudiado DP son aún menores.

Personalmente, no había estudiado DP hasta que mi proyecto también me requería. Incluso entonces descubrí que había usado algunos de los patrones, al menos de manera similar, si no de la manera exacta descrita en el libro. Me sorprendió saber que estaban codificados. Así que busque buenas habilidades de diseño si no conocen DP. Si conocen DP, es probable que sean buenos en diseño pero aún así los prueben. Es posible que solo hayan leído algunas palabras de moda sobre DP o que se hayan enterado de alguna información privilegiada y solo hayan estudiado algunos patrones sin haberlos aplicado.

Es razonable que espere que las personas que solicitan un trabajo con usted sepan (o aprendan) las cosas que se necesitan en su puesto de trabajo, independientemente de si son estándares de la industria o no. De lo contrario, te condenas a la mediocridad. Pero tenga cuidado de hacer que algún conocimiento (o habilidad) sea un requisito laboral, si realmente no es necesario.

Digamos que tiene dos candidatos con antecedentes más o menos similares, y uno puede informarle sobre patrones de diseño, y el otro no. ¿Qué le dirá eso sobre cómo se desempeñarán en el trabajo?

Usted dice que el software existente usa patrones de diseño. ¿Es eso una ventaja? ¿Si es así, cómo? ¿Es su objetivo que el nuevo software escrito se ajuste a los patrones existentes, o que se introduzcan nuevos patrones? ¿Por qué?

Puedo pensar en un desarrollador senior que no conoce los patrones de diseño en la siguiente situación:

1. Solo hay un libro sobre patrones de diseño. Es el libro que los hizo populares en primer lugar. Si la persona no ha leído este libro, es posible que no conozcan los patrones de diseño, o que hayan escuchado sobre ellos, pero no sepan para qué sirven.
2. En cambio, tendrían que saber algo como uml ...
3. Encontrar buena información sobre patrones de diseño en Internet no es fácil. Eres muy afortunado si aciertas la página web correcta que tiene buenos conocimientos de patrones de diseño. Simplemente venir al software después de 1995 podría hacer que una persona no sepa sobre el libro de patrones de diseño, porque el libro es antiguo.

¿Por qué cualquier desarrollador en un entorno que no sea OO debe conocer los patrones de diseño OO? He trabajado en tiendas haciendo solo Cobol, solo PL / SQL, solo Progress 4GL, etc. Los principios de diseño OO son irrelevantes allí, esperaría que las personas mayores en esos entornos tengan conocimiento relevante para esos entornos, no para el diseño OO patrones.

Ser capaz de citar sin pensar de un catálogo de patrones tampoco lo convierte en un buen desarrollador (de hecho, en mi experiencia, produce algunas de las peores piezas de código que he visto). Sin embargo, eso es lo que esperas que sea la marca de un "desarrollador senior". He trabajado en la industria durante 15 años, pero no me pidas que dibuje un diagrama de patrón. Nunca le he dado mucho tiempo, no necesito hacerlo. He adquirido suficiente experiencia para encontrar lo que funciona sin ponerle un nombre específico, y si necesito la definición formal, sé dónde buscarlo (y sí, tengo los libros de referencia en mi biblioteca personal). Esa es la marca del desarrollador experimentado, no el conocimiento de memoria obtenido al llenar algunos libros escolares.