¿Es prudente preguntar acerca de las decisiones de diseño tomadas en un producto durante una entrevista? [cerrado]

Personalmente, me parece que entrevistar a las personas es tan agotador y estresante como ser entrevistado. Pero eso es porque estoy de acuerdo con usted en que el proceso de la entrevista es un intercambio bidireccional.

No me importa lo bueno que seas, no quiero contratarte si no vas a ser feliz trabajando allí. Es un juego caro para jugar. Así que quiero responder a cualquier inquietud que pueda tener y mostrarle el equipo y el producto tal como están, para que pueda tomar una decisión informada.

Cuando busco un trabajo, quiero trabajar con alguien que comparte esa actitud. E incluso si sospecho que conozco las respuestas a las preguntas, les preguntaré solo para ver la reacción. La agresión nunca es una señal de que alguien se sienta cómodo con una situación.

No miento en una entrevista, a ambos lados del escritorio, porque luego piensan que están contratando a alguien diferente / que van a trabajar en un lugar diferente. Y espero lo mismo a cambio, de la persona al otro lado de la entrevista.

Desafortunadamente, eso significa que ocasionalmente me encuentro con entrevistas como la que describiste. ¿Son experiencias horribles? Sí. ¿Salgo de allí sabiendo exactamente dónde salió mal la entrevista? Sí.

¿Pero estoy muy seguro de que cada experiencia horrible hubiera sido considerablemente peor si hubiera obtenido el trabajo o contratado a la persona equivocada? Infierno sí.

Sí, está bien preguntarte si eres realmente curioso y si la respuesta es importante. Creo que preguntar demuestra que entiendes que hay más de una manera de hacer las cosas, y muestra que estás interesado en cómo se escribió el software.

Dicho esto, debes ser muy cuidadoso al formular la pregunta y ser doblemente cuidadoso con la forma en que continúas la conversación. Es fácil darse cuenta de que desafían sus decisiones. Lo último que quieres es que el entrevistador crea que piensas que eres más inteligente que ellos. Si eres genuinamente curioso, pregunta. Si crees que hicieron una mala elección, mantén la boca cerrada.

Si hubiera estado en la situación descrita en la pregunta, en lugar de marcharme podría haber dicho algo como "oh sí, estoy de acuerdo en que la primavera definitivamente no es la solución adecuada para todo. Gracias por informarme un poco sobre su arquitectura! Siempre estoy buscando información sobre cómo elegir las herramientas adecuadas ". (sin embargo, tu pregunta es extraña: preguntas por qué eligieron la primavera, y la eligieron porque no era no ¿todo se acabó todo?)

Como alguien que frecuentemente entrevista a las personas, personalmente agradecería una discusión sobre por qué se tomaron las decisiones de diseño o tecnología en particular, qué haríamos de manera diferente ahora si tuviéramos el lujo de recursos o comenzáramos un nuevo proyecto. En general, lo veo como un signo de alguien que se preocupa por su oficio, y, a menos que sus dogmas y los nuestros no fueran compatibles, probablemente calificaría a ese candidato más que a alguien que simplemente responde las preguntas técnicas de manera competente.

Actualmente estoy trabajando en un proyecto para un cliente que tiene un legado de decisiones arquitectónicas bien intencionadas pero mal implementadas, y candidatos que expresan curiosidad por el mundo tal como es, y el camino a seguir como lo vemos, usualmente son los tipos de personas con las que nos gustaría trabajar. Queremos personas que sean capaces de realizar la debida diligencia y validación apropiadas en las decisiones de diseño e implementación de nuestro equipo. En general, valoramos a las personas que aportan algo a la mesa que no tenemos o de lo que no tenemos suficiente.

Cuando he sido candidato en una entrevista, tomo cualquier señal de hostilidad o actitud defensiva cuando este tipo de discusiones se presentan como una mala señal, ya que una organización que no es capaz de autoexaminarse generalmente también se encuentra en un proceso tecnológico. acumulando que son incapaces y probablemente no estén dispuestos a salir de allí. Si no veo la motivación para la mejora continua en el equipo existente, hay una buena posibilidad de que no sea feliz allí.

Si entré y me dijeron: "Sí, tenemos esta aplicación heredada que no estamos contentos de mantener, pero aún así genera suficientes ingresos para cubrir todos nuestros cheques de pago, y queremos que el código base sea más fácil de mantener. al refactorizar los puntos de dolor, o migrar el componente x a la tecnología y "o" elegimos la tecnología a sobre la tecnología b porque teníamos más experiencia allí y la tecnología b aún estaba en su infancia cuando comenzamos; estamos abiertos al cambio, pero es un proceso lento y no estamos en posición de simplemente lanzar nuestro código base existente ", puedo creer que será una mejor experiencia para mí que si escuchara" Sí, estamos atascados en Borland C ++ Builder versión 6 y los desarrolladores no están No se le permite tomar decisiones técnicas porque todas ellas ya fueron tomadas por el hermano del CEO, quien se acostó con un vendedor de Oracle una vez y decidió que todo el desarrollo futuro se haría usando los servicios web Java 1.4, Oracle ERP y una interfaz de Borland C ++ usando componentes de GUI de terceros en su mayoría, descontinuados y nosotros Preferiría gastar $ 60,000 al mes tapando agujeros para evitar que los clientes salten de la nave en lugar de revisar cualquier decisión y realizar mejoras permanentes que podrían generar nuevos ingresos si tenemos suerte. No muevas el bote, ¿qué te pasa? "

Suponiendo que está en un área con otros trabajos de tecnología, o que está dispuesto a mudarse, es probable que tenga el lujo de elegir. Ningún concierto es perfecto, pero quieres trabajar con personas que quieren trabajar contigo. (Me importa más esto que las opciones de tecnología específicas la mayor parte del tiempo). Si algo huele mal, probablemente lo sea.

Así que sí, pregunta lejos. Cuanto más curiosidad haya por nuestro negocio, nuestro proceso y nuestro diseño, es más probable que tome un candidato. Pero no trabajo en una tienda de Blub, así que no puedo decir si te ayudará a conseguir un trabajo de Blub. Solo puedo decir que funcionaría para usted si desea trabajar con otras personas que se preocupan por su oficio.

  

Pregunta: ¿Es una buena idea explorar las opciones arquitectónicas tomadas en   ¿una entrevista? Si no, ¿por qué?

Absolutamente bien, lo vería como algo positivo.

Si su entrevistador no puede manejar eso, dice mucho sobre ellos, no usted.

Me preocuparía si un junior NO estuviera interesado en las decisiones de diseño, mostraría una falta de curiosidad / interés en el área temática y no mostraría ningún deseo de superarse.

Soy de la mentalidad que es esencial . He trabajado en demasiados trabajos con decisiones de diseño sin sentido porque nadie sabía nada mejor, no le importaba aprender, o había un mandato de la gerencia para usar lo que el CEO leyó en una revista / vio en línea / tenía a alguien Dígale que fue la "próxima gran cosa" sin ninguna consideración de alternativas. Estos trabajos eran todos lugares miserables para trabajar.

No necesariamente debe criticar una decisión de diseño a menos que sea algo que se escupe en el sentido común o simplemente suene como una locura, pero es común cuestionar cosas que parecen "fuera de lugar" para descubrir si hay una razón heredada o algo que surgió que facilitó la necesidad de utilizar un enfoque poco ortodoxo.

Hacer preguntas como esta también tiene el efecto de medir el interés de la compañía en la mejora y la competencia. Como dijo alguien más arriba, es una cosa si obtienes una respuesta como (no sé Java, pero uso .NET, así que usaré ejemplos .NET) Cuando escribimos la aplicación no existían ORM maduros, así que usamos Procedimientos almacenados con una capa de puerta de enlace de datos. Nos gustaría pasar a Entity Framework en el futuro y otra cosa por completo para obtener una respuesta como Simplemente usamos procedimientos almacenados. Entity Framework da miedo y puede requerir trabajo para refactorizar, y no podemos refactorizar nada porque el CEO tiene una lista de nuevas características en las que quiere que trabajemos, y si pasamos el tiempo mirando Entity Framework, nos despedirá. por perder el tiempo . Uno indica comprensión y un deseo de mejorar, el otro indica un entorno mediocre en el mejor de los casos, donde todos hacen lo mínimo para pasar el rato.

Una empresa que se ofende por usted al cuestionar sus decisiones o por querer discutir por qué eligieron usar el Producto A en lugar del Producto B está jugando su mano y demostrando que no quieren un pensador libre sino un drone que no quiere pregunta, y es probable que no sea el tipo de empresa para la que cualquier desarrollador competente quiera trabajar.

respuesta: es una buena idea preguntar acerca de la toma de decisiones arquitectónicas. Pero debes tener cuidado al hacer estas preguntas.

En pocas palabras: debes preguntar " ¿Cómo elegiste la tecnología X sobre la tecnología Y? ".

Desea expresarlo de manera que se comunique que generalmente está interesado en el proceso de toma de decisiones dentro del equipo. Nadie querrá repasar cada decisión heredada que la empresa haya tomado con un candidato.

Cuando pregunta " ¿Por qué eligió la tecnología X en lugar de la tecnología Y? ", es posible que no esté de acuerdo con su decisión (lo cual está bien ... pero se puede tomar como hostil) o que quiere alardear de cuánto sabe acerca de las tecnologías en cuestión (lo que sería molesto para cualquiera), a pesar de sus buenas intenciones.

Me gusta pedirle a un entrevistador que me cuente sobre una decisión de diseño fallida que tomaron y qué se hizo a continuación. Esto te da algunos buenos datos:

1. Si el jefe no puede admitir ningún error de forma o falla temporal, es un jefe para el que probablemente no quieras trabajar.
2. Puede ver cómo la compañía maneja una situación estresante.

Puede que no sea popular, pero siempre tengo un gran respeto por los gerentes que tienen las piedras para reconocer que un proyecto fracasará y lo matará para dejar de gastar dinero, o que algo va en la dirección equivocada y debe serlo. matado o reiniciado.

En última instancia, si estás hablando de satisfacción laboral, la tecnología (idioma / plataforma / compilador / lo que sea) no importa tanto como las personalidades involucradas y el entorno laboral.

Hace unos años, estaba en una entrevista y me habían formulado varias preguntas técnicas sobre un lenguaje de programación ... en las que no había estado bien (60/40 correcto / incorrecto). La discusión se trasladó al proyecto que tenían en mano y comencé a hacer preguntas sobre el diseño y luego les indiqué un par de problemas y limitaciones que presentarían.

Me ofrecieron el trabajo al día siguiente. Desafortunadamente, no pude hacerlo por razones personales.

Hacer preguntas sobre el diseño no debería ser un problema si son preguntas inteligentes, especialmente si puedes relacionarlas con su negocio.

No he hecho muchas entrevistas, pero, según su experiencia, concluiría:

a) Está bien si desea tomar una decisión informada sobre si desea el trabajo;

b) No está bien si ya decidiste que quieres el trabajo.

Las personas pueden ofenderse fácilmente por los comentarios benignos sobre sus elecciones. Ese es un rasgo muy malo, pero uno común.

Aquí hay algunos consejos

1. Preguntar por qué eligieron alguna solución existente podría ser una mala pregunta, porque probablemente el equipo de desarrollo no tuvo la oportunidad de cambiarla o elegirla.
2. También es probable que el equipo ya sepa por qué la tecnología no fue la mejor opción
3. Pero, desafortunadamente, lo último que necesita un equipo de desarrollo es que la gente intente cambiar la arquitectura o cuestione las elecciones que se hicieron hace 10 años; da la impresión de que su tecnología ya es algo antiguo y que los mensajes que existen en el equipo pueden hacer que los desarrolladores estén descontentos con la situación actual
4. Por lo tanto, en una entrevista, lo último que debe hacer es dar la impresión de que se va a quejar todo el tiempo sobre las opciones sobre las que el equipo no tiene control.