Cómo manejar las preguntas de la entrevista sobre el estilo de programación [cerrado]

Como programador de C ++ en entrevistas, repetidamente me encontraba en situaciones en las que el entrevistador quería probar mi conocimiento del buen estilo de programación. Estos generalmente se centraron en el conocimiento básico de OOP.

Sé que OOP es útil para encapsular conceptos y lo uso a diario. Sin embargo, dado que un lenguaje como C ++ permite muchos estilos diferentes y algunos enfoques de C ++ como los algoritmos TMP o STL no son OOP en absoluto (sino más bien como programación funcional), me encuentro atrapado en la mejor manera de "vender" mi conocimiento de otros enfoques como bueno sin parecer arrogante o como alguien sin apreciar lo básico. Me temo que este énfasis en la OOP de los solicitantes proviene de su socialización en los años 90, donde se creía que la OOP era la panacea, pero ese es un punto de vista arrogante.

¿Cómo haría la mejor de las preguntas como esta?

Yo diría que tienes que dar lo mejor de ti respondiendo este tipo de preguntas, como si debieras dar tu mejor respuesta a cualquier tipo de pregunta.

Más adelante, cuando tenga la oportunidad de hacer preguntas al entrevistador, debe plantear el tema y hacer preguntas como:

• ¿Solo haces POO?
• Utilizo un enfoque de programación diferente, ¿cómo es aceptable en su equipo?

Y así sucesivamente ... y de esta manera no solo puede comenzar una conversación sobre la venta de su experiencia con esos otros enfoques, también puede ver cuán rígido y cuánto énfasis se le da realmente a OOP en ese equipo / empresa.

No se preocupe demasiado por las motivaciones del autor de la pregunta, y simplemente responda honestamente. Recuerde, una entrevista es una calle de doble sentido. Usted no quiere quedar atrapado en una empresa ideológicamente inflexible más de lo que ellos quieren quedar atrapados con usted.

Dicho esto, creo que estás siendo un poco paranoico sobre las intenciones de los entrevistadores. Un número asombroso de programadores supuestamente profesionales no entienden los fundamentos de la POO. El 99% de las veces, los entrevistadores no intentan ver si bebiste el OOP kool-aid, sino que solo quieren ver si tienes un conocimiento básico de ello. Incluso si siente que otro paradigma es más adecuado para una determinada solución, los entrevistadores quieren saber que fue una conclusión informada y que no se debe a la ignorancia de la POO.

La racionalización es un mecanismo de defensa muy común cuando alguien no entiende algo. Si las personas no entienden un concepto, argumentan que el concepto es estúpido o inaplicable en lugar de admitir su propia ignorancia. Incluso si realmente piensa que la POO es una mala elección para una respuesta, debe distinguirse de los racionalizadores. La manera de hacerlo es tanto explicar la solución de programación orientada a objetos y por qué piensa que es una mala elección en esa situación.

Quisiera enfatizar que sigues el principio SOLID , que es POO y más. No solo garantiza que su código esté orientado a objetos, sino que está diseñado de tal manera que sustituir objetos siguiendo el principio SOLID es una tarea relativamente sencilla. No solo enviaría el mensaje de que conoces OOP, sino que demuestra que entiendes los puntos sutiles sobre lo que distingue el código OOP bueno del código OOP complicado y hacky escrito por alguien que solía programar en C y cree que todos los demás lenguajes deberían programarse en de la misma manera, ya que seamos honestos, eso es lo que te hace un buen programador, no solo poder usar OOP.

Esté preparado para explicar a fondo para cada uno de los cinco principios por qué cada uno es importante y qué puede pasar con el código que ignora ese principio.