¿Cuándo ser un genio técnico no es suficiente para ser un desarrollador exitoso? [cerrado]

Ha habido mucha discusión sobre la excelente pregunta " ¿La alta reputación en Stack Overflow ayudará a conseguir un buen trabajo? ". Inmediatamente estuve de acuerdo con JoshK que básicamente dijo " No " (explicaré por qué), pero Joel intervino con muchos hechos convincentes que me hicieron votarlo también.

Mi pregunta es ¿qué otras habilidades (además de ser un genio técnico) requieres de un desarrollador? Para conseguir el trabajo o para conservarlo .

Creo que ser un genio está lejos de ser suficiente. Conocí a muchos genios técnicos en varias compañías para las que trabajé y eso me impresionó mucho, pero lamentablemente en muchos casos, simplemente fueron despedidos después de unos meses o puestos en torres de marfil (principalmente debido al motín interno de otros desarrolladores). He visto muchos en angustia personal como resultado de esto, lo que entiendo.

Es por eso que soy un gran admirador de las preguntas no técnicas para puestos técnicos. Me gusta saber cómo interactuará el candidato con otros (incluidos los empleados no técnicos), cuánta consideración tendrá para el negocio, si trabajará para el resultado deseado, y así sucesivamente.

Me gustaría saber qué necesita de sus desarrolladores y POR QUÉ es importante (después de todo, contrata a alguien para que escriba código, ¿no? ¿Por qué querría que fuera asertivo?) . Idealmente, me gustaría que presentara una pregunta de ejemplo que haría durante las entrevistas en apoyo de su respuesta.

Excelentes habilidades de comunicación.

Si sus colegas no pueden leer su cerebro directamente, deberá poder decirles lo que piensa. Preferiblemente tanto verbalmente como escrito.

EDITAR: Una forma de verlos en el momento de la entrevista puede ser preguntándoles cuál es su marco favorito para hacer X, y luego decir que necesitan trabajar en un proyecto donde se pueda usar X, pero es una decisión política usar tecnología Y (que es claramente más antiguo y tiene algunas limitaciones que X resuelve).

Si esto termina en una discusión sobre por qué la decisión política es incorrecta, tiene una fuerte indicación de que esta persona no está bien con las decisiones pragmáticas.

Trabajo en equipo / comunicación:

• para poder explicar sus soluciones o sus problemas
• poder trabajar con otras personas sin que se sientan mal (de ninguna manera); hacer que se sientan trabajando contigo es agradable

Sin esas habilidades, no puede trabajar en equipo, y si no puede, no podrá ingresar a una empresa que lo requiera (y casi todos requieren trabajo en equipo, naturalmente). Aún puede ser independiente y trabajar en proyectos que no tienen otras personas para trabajar, pero aún tiene que comunicarse con personas de otras compañías.

Incluso para aprender, si no puedes comunicarte con muchas personas diferentes, como en la web, entonces es posible que no puedas mejorar en la vida real y en la sociedad (sea cual sea el trabajo) es una desventaja.

editar> En la entrevista, el trabajo en equipo / socialización / comunicación es realmente fácil de verificar, podría ser lo más fácil. Solo tiene que hacer algunas preguntas, no técnicas, preguntas fáciles de responder o simplemente preguntas sobre lo que el candidato piensa sobre algo o lo que le gusta o no le gusta en un dominio u otro. Hazlo hablar. Verás.

La persistencia es una habilidad que no veo mencionar mucho. Y es una habilidad: la capacidad de resolver un problema, incluso si no puede ver el final. Mucha gente no hace esto; funcionan solo con impulso, o simplemente hacen lo mínimo para sobrevivir. Desafortunadamente, no hay forma de saber si una persona tiene este rasgo hablando con ellos. Realmente necesita poder hablar con otras personas que han trabajado con la persona. Las referencias pueden hacer esto, pero esa opción no siempre está disponible.

Estos son más rasgos que habilidades, pero probablemente sugiera que vale la pena encontrarlos en alguien para ser un desarrollador exitoso:

La versatilidad sería otro rasgo que pondría allí. A veces, un desarrollador puede tener que ocupar roles fuera del desarrollo puro, por ejemplo, analista de negocios, arquitecto o probador. Sé que he tenido varias partes en proyectos donde estoy haciendo algo más que diseñar o escribir código y esto debería ser algo que ver en otro. No todos pueden aceptar asumir esos otros roles. Pregunte qué tipo de situaciones ha tenido el desarrollador en el pasado donde tuvo que desempeñar otro rol y cómo resultó.

La humildad sería otra que probablemente pondría como requisito. El ego puede causar muchos problemas en algunos lugares y no todos pueden aceptar que puede haber alguien mejor en algo que ellos. Si alguien más tiene una mejor idea, que sea lo que se haga. Es posible que tenga una muestra del código del desarrollador que le pide que critique y vea qué tan bien pueden corregirse o no.

El orgullo sería otro para poner ahí abajo. Esto contrasta con la calidad anterior, pero si alguien no siente orgullo por su trabajo, ¿qué calidad cree que es? No estar satisfecho es ligeramente diferente aquí, ya que probablemente muchos desarrolladores pueden ser perfeccionistas. Pregunte de qué proyecto pasado se sienten más orgullosos.

La automotivación también sería una habilidad importante para ver. ¿Qué los impulsa? ¿Qué tan bien pueden articular esto? "Office Space" tiene esta línea de Peter Gibbons:

Ocho, Bob. Entonces eso significa que cuando cometo un error, tengo ocho personas diferentes que vienen a contarme al respecto. Esa es mi única motivación real para no ser molestado, eso y el miedo a perder mi trabajo. Pero ya sabes, Bob, eso solo hará que alguien trabaje lo suficiente para no ser despedido.

Eso es algo con lo que sospecho que muchos desarrolladores y no desarrolladores pueden relacionarse. ¿Por qué haces el trabajo que haces? Esta puede ser una buena pregunta, pero busque la sinceridad y la autenticidad en la respuesta, ya que a veces pueden ocurrir respuestas enlatadas que uno tiene que detectar.

La curiosidad sería la última en agregar a mi lista. El deseo de ver cómo funciona algo, aprender nuevas tecnologías y salir de la zona de confort, son otros marcadores de esto que se pueden encontrar en desarrolladores exitosos. Una breve historia sobre cómo uno entra en el desarrollo puede ser una forma de ver este rasgo, pero otra es preguntarles sobre algo que no han visto y ver si tienen un "Bueno, eso podría ser interesante para explorar" o un " Oh hermano, no eso otra vez, "tipo de mirada.

1) La comunicación es probablemente la habilidad más importante para cualquier persona, incluidos los tipos de ingeniería de software. Esas habilidades de comunicación son igualmente importantes para tratar con gerentes y clientes como lo son para tratar con compañeros de trabajo.

2) El trabajo en equipo es una habilidad ligeramente diferente que depende en gran medida de la primera. Esencialmente, necesito determinar si la persona que estoy tratando de contratar beneficiará al equipo en su conjunto, o habrá algunos conflictos de personalidad que potencialmente estoy contratando. Nadie puede predecir el futuro, pero tampoco puede ignorar las señales de advertencia en la entrevista.

Una táctica que uso en el proceso de la entrevista es pedirle a la persona que describa uno de los problemas técnicos más desafiantes (de los que puede hablar) y cómo los resolvió. A medida que hablan sobre su proceso de razonamiento y cómo descubrieron el problema, puede tener una mejor idea sobre qué tan bien pueden comunicarse sobre cosas potencialmente complicadas. Si buscan ayuda adicional en el proceso, lo veo como una ventaja. Ninguno de nosotros somos tecnólogos perfectos. Si el problema que eligieron terminó siendo un choque de personalidades (que solo sucedió una vez), puedes pasar o investigar un poco más.

En muchos sentidos, el proceso de entrevista es como ir a una cita a ciegas. Ambas personas están poniendo su mejor cara, tratando de averiguar si quieren pasar más tiempo con la otra parte. Cuanto más pueda hacer que la entrevista fluya como una conversación, más relajado estará el entrevistado; y, en consecuencia, mejor verás si encajan bien.

Aunque es una cualidad que puede ser más aplicable al equipo que a los desarrolladores individuales, creo que hay mucho detrás del dicho: "Grandes ingenieros se envían".

Es algo que sería difícil de demostrar en una entrevista para la mayoría de las personas, pero si estuviera entrevistando a un candidato que, por ejemplo, había creado y enviado una aplicación, biblioteca o marco de código abierto sustancial y podía hablar elocuentemente sobre algo adicional que se necesita para terminar realmente un proyecto no trivial, tendría que darle a esa persona una ventaja sobre su competencia.

Por el contrario, si un candidato potencial me indicara su cuenta de Github y vi que estaba llena de proyectos a medio completar, con errores, descuidados o mal documentados, tendría una buena razón para ignorar su candidatura.

"El café es para cerrar", como dijo un hombre en una película una vez.

Las habilidades de comunicación y trabajo en equipo son importantes, pero agregaría que poder comprender los requisitos del cliente y adquirir conocimiento del dominio comercial también ha sido muy importante en mi experiencia.

Estoy de acuerdo en que las comunicaciones son primordiales, pero he experimentado un fallo en un excelente codificador que no mostraría a otros ingenieros el uso de sus procesos. Pude duplicar sus procesos y mostrárselos a otros, pero sin su ayuda. Lo despidieron porque no quería enseñar.

Nunca es suficiente.

Sentido común. Resolución de problemas Interés por la tecnología en su conjunto. Actitud de hacer las cosas de la manera correcta. Persistencia. Juego en equipo / Comunicación.

Califica cada habilidad en 1-5. Si tienes min 3 y en promedio 20+. Tendrás una buena vida como desarrollador. 25+ serán desarrolladores exitosos. Menos de 10 y necesita pensar seriamente en una carrera en desarrollo de software.