Estaba ojeando varias páginas (como ésta) que (supuestamente) recogen ejemplos de preguntas sobre UML hechas en entrevistas reales de trabajo.

A mi me parecen justamente ejemplos de lo que NUNCA deberías preguntar en una entrevista. ¿De qué sirve preguntar cuántos diagramas diferentes tiene UML? o ¿cómo se dibuja un método estático de un diagrama de clase? o aún peor, ¿quién inventó UML y cuándo? .

Responder correctamente a estas preguntas sólo prueba que el candidato conoce la notación UML y la teoría del lenguaje pero no sirve en absoluto para saber si el candidato es bueno modelando que de hecho es lo único que importa (o debería importarnos).

Todo el mundo es capaz de memorizar datos acerca de una notación pero no todos son capaces de aplicar esa notación en el modelado de un sistema real. Por ejemplo, como profesor de UML, yo mismo he visto muchos estudiantes incapaces de saber si un determinado concepto del dominio real debería modelarse como una clase, como un atributo o como una asociación, aún sabiendo perfectamente la definición de cada tipo de elemento y su representación gráfica. Y ya no digamos si la solución del diagrama de clases propuesto requiere usar una clase asociativa. Todo el mundo sabe decirte que una clase asociativa es al mismo tiempo una clase y una asociación pero las barbaridades que he llegado a ver cuando los alumnos intentan poner en práctica este concepto.

De hecho, todavía es más preocupante ver este tipo de preguntas en algunos exámenes de universidad. Algunos profesores siguen sin “pillar” que deberían enseñar modelado de software y no UML. UML es sólo una manera de expresar gráficamente (o textualmente) unos modelos (y de hecho, sólo una de las varias alternativas posibles).

Enseñar UML sin enseñar a usar UML solo sirve para generar más informáticos frustrados, convencidos de la inutilidad del modelado de software. Click To Tweet

Y hablo de preguntas de UML porque es lo que conozco más de cerca pero me atrevo a decir que un problema parecido existe cuando las empresas intentan evaluar los candidatos para puestos de programación. En estos casos es muy habitual preguntar por ciertos algoritmos “clásicos” de manipulación de estructuras de datos. Los mismos que estudiaste en la carrera y que nunca has usado después en tu vida profesional (bueno, usarlos sí que los has usado, pero nunca los has reescrito tu mismo si no que has usado alguna de las muchas librerías existentes que los implementan de forma eficiente).

Imagen de cabecera por Hian Oliveira en Unsplash