¿La ingeniería excesiva es una señal de advertencia? [cerrado]


22

Por lo tanto, presentamos un ejercicio de codificación directo a los nuevos candidatos con algunos requisitos bien definidos. Ocasionalmente, recibimos soluciones que realmente no resuelven el problema en cuestión, pero están sobredimensionadas para resolver un problema percibido, a menudo fuera de los límites del ejercicio.

Ahora mi pregunta es, ¿es esta una señal de advertencia?

EDITAR: Gran parte de la discusión se basa en que la prueba es defectuosa, lo cual es un punto justo. Como describí en un comentario, la premisa básica de la prueba es mostrar cómo puede leer los datos del archivo de una manera sensata (y se sorprenderá de la variedad de enfoques que vemos) y cómo hacer coincidir los elementos antes de calcular la latencia entre las actualizaciones. Ahora, para que esto funcione, se deben hacer ciertas suposiciones sobre los datos, y buscamos estas suposiciones, y también declaramos explícitamente que queremos ver el enfoque que toma (incluido el enfoque OO, etc.) Todo esto en dos horas. periodo de tiempo.

En mi humilde opinión, cuando estaba entrevistando fue el ejercicio más completo que encontré.

El escenario particular sobre el que estoy reflexionando es donde un candidato, en lugar de leer el archivo, aceptó la entrada de "red" en una aplicación multiproceso, que claramente no está dentro del alcance.


43
¿podría incluir un ejemplo de lo que es el ejercicio? El problema podría estar en el desafío y no en el candidato.
Reactgular

13
¿Estás seguro de que los candidatos entendieron el problema presentado en el ejercicio? Directo a la persona que presenta el ejercicio no siempre es igual de directo al candidato bajo estrés para realizar.
cdkMoose

23
¿El hecho de que lo haya llamado "ingeniería excesiva" no dicta la respuesta? Es como preguntar "¿Es un candidato demasiado confiado una señal de advertencia"? Claro, a menos que solo tenga confianza, pero ya ha puesto su conclusión en la premisa de la pregunta.
psr

3
@MathewFoscarini ¿La ingeniería excesiva no es siempre negativa? Implica que la persona se enfocó en las cosas incorrectas e implementó una solución que es innecesariamente compleja, lenta o difícil de entender y mantener. ¿Cómo podría no ser percibido como un defecto?
Andres F.

2
@AndresF. Es una entrevista. Sobre Ingeniería la respuesta a una pregunta en una entrevista dado que la mayoría de las entrevistas duran solo una hora. Podría ser un logro. Sí, escribir 1,000 líneas de código para ordenar algo es sobre ingeniería, ¡pero escribió 1,000 líneas de código en menos de una hora! Si la ingeniería excesiva es un problema que debe filtrarse en el proceso de la entrevista. Debería haber una prueba más específica relacionada con el alcance y la complejidad del diseño. Prefiero darle a la persona un desafío arquitectónico de software para resolver. Por ejemplo; "crear un diagrama UML para un sistema de automóvil autónomo".
Reactgular

Respuestas:


48

El problema es que la prueba está sesgada. Le está pidiendo a alguien que demuestre su capacidad para escribir software complejo de nivel empresarial mediante un ejercicio simple que solo toma unos minutos. Hay otros entrevistadores en otras compañías que se quejan de que los candidatos no muestran suficiente habilidad en el diseño orientado a objetos con estos ejercicios, por lo que las personas tienden a compensar en exceso. No significa necesariamente que su candidato sea incapaz de usar un código más simple cuando la situación lo amerite.

Si desea saber si ese es el caso con su candidato, simplemente pídale que lo vuelva a hacer, dándole algunas pautas específicas. Diga: "Puedo ver que estaban mostrando sus habilidades de diseño orientado a objetos, pero parece excesivo para un problema tan simple. ¿Pueden reescribirlo usando solo dos funciones pequeñas?"


55
¿Dónde en la pregunta dice "software complejo de nivel empresarial"?
Reactgular

12
@Nim: creo que el punto de Karl es que lo que usted considera sobreingeniería, otros entrevistadores pueden considerar una buena representación de la comprensión del OOD por parte del entrevistado. La referencia al pseudocódigo puede no ser tan explícita como cree al describir el tipo de enfoque que espera.
Mike Partridge

77
No estoy diciendo nada sobre tus intenciones, @Nim. Los candidatos leen cosas en preguntas que no se mencionan explícitamente, y muchos entrevistadores realmente esperan eso. Los candidatos no tienen forma de saber si eres ese tipo de entrevistador o no, por lo que se equivocan.
Karl Bielefeldt

55
@KarlBielefeldt: sí, a veces la gente lee cosas en preguntas que no se mencionan explícitamente, por ejemplo, en preguntas formuladas aquí en PSE ;-)
Doc Brown,

3
¿Qué pasa con una solución simple de simplemente agregar una oración al final del ejercicio que dice "describir en el menor código posible" o algo en esos términos
User60812

30

Diría que esta es una clara señal de advertencia, pero no necesariamente descalifica a un candidato.

Hay dos problemas separados que los candidatos parecen estar teniendo:

  1. Perder el objetivo del ejercicio : esto es bastante alarmante. Toda la habilidad de programación en el mundo no creará un buen resultado si alguien no puede resolver el problema que está resolviendo correctamente. He descubierto que los ingenieros más productivos son los que pueden identificar el verdadero problema a resolver, incluso si no es exactamente el problema planteado. Tener la capacidad de pensar críticamente sobre la pregunta que se hace y quizás reformularla en algo que sea más fácil de resolver es una habilidad crítica. Perder el punto cuando el problema se está planteando claramente debería ser una gran bandera roja.
  2. Ingeniería excesiva de la solución : este es un problema secundario y, a menudo, es el resultado del primer problema. Hay un par de patologías diferentes que pueden tener este resultado. Primero, no entender adecuadamente el problema, o lanzarlo de manera demasiado amplia puede dar como resultado una solución que es demasiado compleja. Esto está claramente relacionado con el primer punto anterior. En segundo lugar, tratar de "alardear" al pensar en escenarios futuros que podrían no ser realmente relevantes. Esto puede ser problemático porque indica que el candidato no ha entendido el valor de la simplicidad en las soluciones y difiere la complejidad hasta que sea realmente necesario. Esto es algo que puede corregirse con una buena orientación, pero es importante tener cuidado al traer a alguien a la organización.

Sugeriría hacer un seguimiento con el candidato sobre su respuesta durante el curso del proceso. En lugar de simplemente mirar su resultado, trate de determinar qué los llevó al resultado y, a modo de orientación, cómo responderían y cambiarían su respuesta. Esto probablemente será más revelador sobre sus capacidades que solo su respuesta directa al problema. Los "porqués" de su enfoque pueden darle una idea de si simplemente no lo están entendiendo, o si su comprensión fue ligeramente diferente en la forma en que decidieron responder. Este tipo de seguimiento también revelará más sobre su enfoque general para la resolución de problemas.

Además, vuelva a examinar el problema en sí mismo y vea si tal vez no está claro y tal vez está causando que la gente se equivoque al formular sus respuestas.


23

No, no durante una entrevista de trabajo. Demasiados entrevistadores hacen cosas como especificar de manera intencional los requisitos y esperan que el entrevistado haga más preguntas o preste atención a problemas del mundo real que no se mencionan explícitamente.

Aquí hay algunas cosas, fuera de mi cabeza, que sus requisitos probablemente no mencionaron:

  • Estándares de codificación

  • Comentarios

  • Manejo de excepciones

  • Nombres descriptivos de variables, clases, métodos.

  • Seguir el uso idiomático del idioma

  • Diseño orientado a objetos adecuado

  • Atención a posibles problemas de concurrencia.

  • Escribir casos de prueba para el código

¿Prestaste atención a una sola de estas cosas sin decirlo explícitamente? ¿Cómo sabría el candidato cuáles le interesan y cuáles no?

Una entrevista es un entorno altamente artificial. El entrevistador a menudo intenta "engañar" al candidato un poco para que sea difícil para el entrevistado decirle lo que quiera escuchar, y el entrevistado está tratando de adivinar lo que realmente quiere el entrevistador .

En general, cometer un error en esa suposición es bastante diferente de cometer un error en las decisiones de diseño del mundo real. Si quieres saber si alguien sobre-diseña cosas, probablemente tengas que hablar sobre diseño en lugar de mirar un ejercicio de codificación muy artificial.


Nunca he visto esto hecho. En la actualidad, la mayoría de las empresas quieren la solución más simple y sucinta. Sería cauteloso sobre trabajar para cualquier empresa que no pueda presentar una solicitud adecuada, y por falta de un solicitante que pueda entender "requisitos claros", no lo contrataría.
Shaun Wilson el

1
@ShaunWilson: Eso depende mucho. Me imagino que las grandes empresas podrían estar interesadas en ver qué puede hacer con especificaciones claras. En equipos más pequeños, las personas dependen de las habilidades de los demás para empatizar, extrapolar, leer entre líneas y explorar el espacio del problema usted mismo.
back2dos

@ShaunWilson Lo he visto muchas veces. Asigne una tarea, incluso dígale al candidato que ignore cosas como la verificación de errores y proporcione solo los elementos básicos, luego reprobéelos porque no incluyeron todos los casos de esquina y contingencia. Tristemente es muy, muy común.
Jwenting

Para un ejercicio de codificación, es demasiado esperar que los candidatos se apeguen a los estándares y el estilo de codificación, pero la coherencia es una expectativa justa. Esperamos que los candidatos usen el idioma de manera idiomática, pero no buscamos casos de prueba: el plazo es de solo dos horas (creo que no es realista). No creo en los trucos en las entrevistas, no tiene sentido. estado en esas situaciones antes, y francamente encuentro que son un viaje de ego para el entrevistador y es mejor evitarlo. Mencionamos explícitamente OOD (y, sin embargo, es sorprendente ver soluciones que no usan OO ..)
Nim

@jwenting, permíteme asegurarte que no hacemos tal cosa, eso no es nada. Sin embargo, si continuamos, hablaremos en las entrevistas de f2f sobre cómo podrían expandirse para agregar casos de esquina, pero solo si los candidatos lo mencionan.
Nim

12

En mi humilde opinión, la respuesta es claramente , es una señal de advertencia, si

  • el ejercicio de codificación tenía una tarea clara
  • tiene requisitos bien definidos (y también bien escritos),
  • los candidatos tuvieron la oportunidad de hacer preguntas para asegurarse de resolver el problema correcto.
  • quieres personas inteligentes y que hagan las cosas en tu equipo, no astronautas de arquitectura .

1
+1 para el elemento interactivo. En muchos casos, las especificaciones son vagas, incompletas o contienen terminología específica del dominio. Sin una oportunidad para aclarar cualquier problema, puede ser inapropiado culpar al candidato.
HABO

1
+1 por el hecho de que su respuesta modela el proceso perfectamente. Claramente respondiste exactamente la pregunta que hizo el OP.
dcaswell

1
+1, este es mi proceso de pensamiento actual, supongo que es bueno ver que no es ingenuo ni tonto ... Gracias por los dos enlaces de Joel ...
Nim

1
No se apresure a despreciar a los astronautas de la arquitectura. Ser astronauta de arquitectura es una fase por la que debe pasar un desarrollador antes de convertirse en un programa de cinta adhesiva verdaderamente competente. Vea esta respuesta de Aaronaught a Frankly, ¿prefiere la codificación Cowboy? pregunta.
Marjan Venema

1
@MarjanVenema: Tengo dudas de que Aaronaught significara la palabra en el mismo sentido que Joel Spolsky, quien creó ese término. Y honestamente, no creo que haya "despreciado" a nadie: si quieres que los desarrolladores de tu equipo creen, bueno, digamos soluciones visionarias, no dudes en contratarlas.
Doc Brown

5

No es una señal de advertencia tan grande como no resolver el problema en cuestión . El hecho de que haya fallado el cuestionario y no haya proporcionado la solución correcta es una señal de advertencia. No es necesariamente un escenario prohibido porque depende de cómo y por qué no proporcionó la solución correcta.

Muchas veces la pregunta es una mierda completa y simplemente sin respuesta. No finjas que los entrevistadores nunca cometen errores. Todavía es un fracaso de su parte descubrir por qué la pregunta es una mierda. Si está contratando a un ingeniero que se espera que lo ayude a hacer los requisitos, esto es un problema. Si está contratando a un programador, simplemente no espera que lo haga.

Suponiendo que el ejercicio de codificación no está terriblemente desordenado, parece que la forma en que falló fue malinterpretar el problema y meterse en la maleza tratando de resolver un problema que no estaba allí. Sí, esa es una señal de advertencia.


3

Tal vez.

No resolver el problema es, por supuesto, una clara señal de advertencia de que algo está mal. ¿Qué salió mal? O entendieron mal el problema o hicieron una mala solución. Una mala solución para algo simple es una señal clara de que el candidato es pobre.

Si entendieron mal el problema, analice detenidamente sus requisitos. Incluso las cosas que le parecen claras como el cristal pueden no ser claras para otras personas que no están familiarizadas con un dominio, o de un entorno diferente (ubicación, edad, educación). Si el candidato estaba allí en la sala con usted, o si le ofreció la oportunidad de hacer preguntas y aún falla, lo consideraría un fracaso de su parte. Si los requisitos se pasaran por alto, probablemente les daría el beneficio de la duda (y pensaría en arreglar el proceso de la entrevista).

Si la solución fue correcta, entonces se vuelve menos clara. Personalmente, creo que varias personas llevan YAGNI demasiado lejos. Si puede resolver un problema específico y crear una solución general sin aumentar la complejidad o dañar la capacidad de mantenimiento, ¿por qué no hacer la solución general? (Piense en revertir una cadena vs. revertir cualquier colección) Ese tipo de "sobre-ingeniería" es claramente bueno en mi opinión.

Todo lo demás es ese término medio gris. ¿La solución aborda los posibles ejes de cambio? ¿La solución agrega complejidad o daña la mantenibilidad? Agregando un poco de complejidad para resolver problemas futuros que están casi garantizados para ganar. Dañar mucho la capacidad de mantenimiento para dar cuenta de algo que es totalmente improbable no lo es.

Ser un buen ingeniero de software significa lograr el equilibrio correcto aquí. Ser un buen entrevistador significa lograr el juicio / inferencia correcto sobre cómo y por qué el candidato eligió ese equilibrio, a menudo utilizando otras partes de la entrevista para evaluar.


2
Si el problema es difícil de entender, o no se ha comunicado bien, este es el momento para que demuestren la habilidad crítica que DEBEN tener los programadores buenos a moderados: definir el problema.
Adam Davis el

La pregunta no dice que el candidato no aprovechó la oportunidad de hacer preguntas.
dcaswell

3

Quizás pero considere lo siguiente:

  • Las entrevistas son difíciles: las personas están estresadas. Esto debe tenerse en cuenta en cualquier problema que le des a alguien

  • Longitud del requisito: ¿Qué tan largos y directos son los requisitos? ¿Les hiciste palabras extra para asegurarte de incluir todo? Como resultado, pueden ser claros para usted, pero los requisitos pueden ser excesivamente diseñados. Tomé una entrevista de trabajo una vez por un problema de hora con aproximadamente 3 páginas de texto para un problema que era relativamente simple. A veces, todo ese texto puede ser difícil de leer e interpretar en una entrevista y también puede malinterpretarse.

  • A veces menos es más: preferiría tener algunos puntos, oraciones y ejemplos que muestren los requisitos principales y luego una discusión con alguien para hacer preguntas y tal vez contactar en el camino si es necesario. Supongo que lo que estoy tratando de decir es que primero debe verificar que los requisitos de su prueba no sean demasiado complicados para un problema simple.

  • Habilidad de comunicación: primero debe probar la capacidad de los candidatos para comunicarse y hacer preguntas inteligentes sobre el problema y una vez que sepa que han demostrado que entienden el problema, puede exponerlos sobre su implementación.

  • En pocas palabras: si no ha comprobado que se comprende el problema, realmente no sabe qué hacer con la sobre ingeniería. Como otros han dicho, podría ser algo bueno o malo, pero si no verificó la comprensión o no se comunicó con el candidato sobre el problema por adelantado, es más difícil saber su comprensión general del problema y qué hacer con él.


1
Respuesta sólida, pero es difícil atravesar el muro de texto. Considere editar su respuesta y desglosar las secciones principales.

2

Mucho de esto podría atribuirse a cómo formula la pregunta y cómo ha puesto toda la entrevista en perspectiva.

Es como, "Veamos qué tan creativo eres. ¿Qué es 2 + 2?" Cuatro? Todo lo que se te ocurre es la respuesta más simple, obvia y precisa. Los desarrolladores jóvenes / principiantes que están tan ansiosos por impresionar durante una entrevista tomarán el "Queremos probar sus habilidades de codificación o ver qué tan buen programador es usted". significa "hacer algo muy sofisticado". A todos nos gusta pensar que lo simple es mejor, excepto cuando hace las cosas más difíciles.

Hay maneras de ver si alguien es propenso a estar siempre sobre ingeniería. Dé un ejemplo de código de algo que era demasiado complejo y solicite una solución más simple. Cuando alguien proporciona una solución que no cree que funcione, esta es una gran oportunidad para ver cómo reacciona ante las críticas. Personalmente, me gustaría ver a alguien abierto a nuevas ideas y reconocer una solución mejor que alguien que va a cometer los mismos errores una y otra vez.

Y en realidad, ¿no siempre tenemos la oportunidad de cambiar nuestro código cuando no funciona? Puede bajo diseño o sobre diseño inicialmente. Una vez que haya reconocido la solución simple, ¿no debería ser más fácil de implementar?


"¿Qué es 2 + 2?" 4 versus "Veamos qué tan creativo eres. ¿Qué es 2 + 2?" El límite de la secuencia 3.9, 3.99, 3.999, 3.9999, ...
emory

"Veamos qué tan creativo eres. ¿Qué es 2 + 2?" 5, para valores suficientemente grandes de 2.
Michael

y definir "sobre ingeniería". Dependiendo del entorno, algo que puede parecer excesivamente diseñado para alguien que no está familiarizado con él puede considerarse que toma demasiadas libertades y atajos para alguien en ese entorno. Piense en el software de control de misiles cuando lo mira alguien cuyo campo principal es escribir juegos para teléfonos móviles ...
comenzó el

2

Depende, pero generalmente no.

El diseño en general es una habilidad aprendida con experiencia. La descripción de Aaronaught de esa progresión vinculada por Marjan es generalmente buena.

La comunicación en cualquier forma también depende mucho del contexto. Lo que puede parecer perfectamente claro en el sentido de una cosa en un contexto, también puede significar claramente algo más en un contexto diferente. Saber qué preguntas hacer es también algo que viene con la experiencia.

Su proceso de pensamiento y cómo razonan sobre sus decisiones es mucho más importante que su solución. Sin revisar su solución y sus decisiones con ellos, no puede evaluar completamente el contexto en el que se desarrolló.

Dada la progresión anterior, un candidato con la solución sobredimensionada puede estar más avanzado que el candidato con la solución simple.

Además: ¿para qué posición de nivel estás contratando? El exceso de ingeniería de un candidato de nivel de entrada o intermedio es menos problemático que el exceso de ingeniería de un candidato de nivel superior.


1

Si el programador no resolvió el problema, todo el código adicional es el intento del codificador de ofuscar la falta de respuesta. Es la misma técnica utilizada en una prueba de ensayo por un estudiante que no sabe mucho sobre el tema. Él o ella divagarán sobre un tema convincente pero no relacionado con la esperanza de que su ignorancia esté enmascarada por el recuento de palabras.

Si el programador resolvió el problema pero agregó mucho más código, considere los antecedentes del programador, ya que algunas áreas de programación requieren mayores tolerancias que otras.

Por ejemplo, el código que ejecuta el piloto automático en un avión comercial de pasajeros tiene muchas menos tolerancias al fracaso que un juego gratuito de Android. Un desarrollador acostumbrado a programar dispositivos embebidos que son difíciles de alcanzar y casi imposibles de actualizar tenderá a codificar más, y si es un desarrollador que puede enviar 15 actualizaciones en un día.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.