El efecto de ReSharper en la codificación de entrevistas [cerrado]

Cualquiera que haya usado R # o CodeRush sabe lo rápido que puede armar construcciones simples (y refactorizar complejas) con un atajo de teclado simple. Sin embargo, ¿estos complementos de productividad causan una evaluación falsa de la capacidad durante las entrevistas?

Parte de ser un escritor de código productivo (y causar una buena primera impresión en una entrevista) es escribir un buen código, rápido.

Si tuviera dos candidatos:

1. No usa complementos. Piensa en el problema, se sienta en un IDE de stock en la PC de la entrevista que se ve exactamente como el suyo y escribe el código en un minuto o dos, como de costumbre. Hecho. Pasar.

2. Utiliza complementos. Piensa en el problema, se sienta en un IDE de acciones en la PC de la entrevista y se da cuenta de que "fe + tab" ya no escribe un bucle foreach automáticamente, y todos los accesos directos se han ido. Luego se tambalea alrededor del teclado, golpea sus teclas de acceso rápido normales y abre ventanas extrañas y se pone nervioso. Le lleva 3 minutos escribir lo que normalmente llevaría 30 segundos. Hecho. Parecía que a veces no conocían el IDE. Debe ser nuevo en este IDE y, por lo tanto, no tener mucha experiencia con él ni con el idioma. Pase, pero una marca 'meh' al lado de su nombre.

En su experiencia, ¿cómo maneja los complementos durante las entrevistas como entrevistador o entrevistado? ¿Cuáles son las mejores prácticas para obtener lo que el candidato realmente sabe? Puede haber candidatos que no entiendan el código y usen R # como muleta. También puede haber candidatos que conozcan el código dentro y fuera y usen R # porque es simplemente más rápido que las plantillas integradas VS o Eclipse. ¿Es mejor no usar un IDE? ¿Dejar que traigan su propia PC? ¿Otros?

Fui candidato 2 en una entrevista muy recientemente . Me dieron una instalación estándar del IDE en una PC con un teclado no estándar y un marco de prueba desconocido, y me pidieron que escribiera una aplicación simple de Fizz-Buzz con pruebas unitarias. Lo esponjé. Debo haber parecido un novato completo, tropezando en la oscuridad tratando de hackear el código. No hace falta decir que no me ofrecieron el puesto.

Lo que aprendí es que confío mucho en mis complementos. No solo escriben el código más rápido, sino que configuran la forma en que pienso sobre el código y la forma en que hago la codificación. Por ejemplo, solía pensar con mucho cuidado sobre los nombres de variables porque podrían ser difíciles de cambiar después del hecho. Ahora, por el contrario, solo adivino a medias cómo usaré la variable, piratearé un código, dejar que la variable me diga para qué sirve y luego presionar Refactor-> Cambiar nombre para llamarlo algo más apropiado .

¿Esto me convierte en el candidato menos capaz? De alguna manera, creo que sí . Alguien que puede escribir código en el Bloc de notas y compilarlo y ejecutarlo correctamente tiene ciertas ventajas sobre alguien como yo que necesita toda la bondad IDE que puede obtener. Desde ese punto de vista, entiendo perfectamente por qué cualquier compañía elegiría no contratar un cabezal de herramientas como yo.

Por otro lado , sigo siendo un desarrollador senior talentoso y capaz. Aprendí lo que funciona para mí y practico el tipo de pereza que me hace productivo, dadas mis propias debilidades y limitaciones. En resumen, soy el tipo de programador que realmente podría beneficiar a una empresa como la que me rechazó .

Curiosamente, tuve otra entrevista hace un par de semanas. Después de mi experiencia previa, pregunté por herramientas o presupuesto adicionales para comprarlos. Descubriendo que no eran ni me dieron una razón más para rechazar a la oferta (en lugar generoso) que se hicieron a mí .

Entonces, parafraseando a Groucho, " no me uniría a ninguna compañía que tuviera a alguien como yo como empleado " .

No, a menos que me dejen usar ReSharper, de todos modos.

Permítales ( candidatos, es decir ) usar lo que quieran. El viejo, construye un Wal-Mart con una navaja suiza solo para demostrar que puedes acercarte es tan viejo. Van a usar lo que sea necesario en su trabajo diario (bueno, eso espero), así que déjenlos usar lo que quieran en una entrevista. El resultado final es todo lo que importa. Con mucho más gusto contrataré a un candidato que sepa qué herramientas están disponibles en el mercado y cómo usarlas de manera eficiente, y luego a quien lo haga todo manualmente. Esta es una industria asesina.

ps Como ejemplo, piense en Vim (o Emacs): ¿le gustaría usarlo sin configuraciones personalizadas, complementos, etc.?

Yo diría que herramientas como ReSharper realmente te hacen un mejor candidato sobre todo.

Por un lado, algo como ReSharper le enseñará sobre construcciones de lenguaje que quizás no haya conocido, así como mejores formas de organizar su código para pensar en un problema o estructurarlo para facilitar su lectura. ReSharper, en cierto sentido, te mantiene al tanto de las mejores prácticas para lanzar código, en lugar de permitirte recurrir a hábitos malos u obsoletos, o peor aún, al mal tipo de pereza.

Un buen codificador necesita comprender las construcciones básicas, pero no escribirlas manualmente. El buen tipo de pereza permite que las herramientas hagan el trabajo aburrido, y el tiempo extra ahorrado se dedica a pensar en el problema. Esto hace que uno sea un mejor desarrollador en general.

Completaría la línea de razonamiento afirmando que si el proceso de entrevista favorece palos y cuchillos de piedra, está fundamentalmente roto.

Esa es una de las razones por las que le pido a la gente que codifique en la pizarra, no en el IDE. Nivela el campo de juego. Y la gente dice "oh querido, resharper maneja esto por mí por lo general". Diablos, los fragmentos integrados manejan bucles y demás, que la pizarra no puede proporcionarle. En ese caso, decir algo como "Espero que la puntuación esté ahí; soy un tipo R #" es probablemente todo lo que necesita para evitar que tenga algunos problemas de sintaxis en su contra.

Necesito cierta habilidad para escribir código comprensible en la pizarra para que podamos tener una reunión en la que resolvamos cómo vamos a hacer las cosas. Y, por supuesto, quiero ver si alguna vez has escrito código en tu vida o no. Tus entrevistas pueden variar.

Gran pregunta, por cierto: a menudo he reflexionado sobre esto.

El dominio de las herramientas es una habilidad que es fundamental para ser un buen desarrollador. Siempre he sentido sonar las alarmas cuando un desarrollador afirma que prefiere codificar en el bloc de notas a usar un IDE. Sugiere que está más interesado en el proceso que en el producto.

Es como preferir labrar la tierra con una azada frente a un tractor, bien si eres un jardinero aficionado, pero insostenible como agricultor industrial en una economía competitiva.

Sin embargo, nos hacemos dependientes de nuestras herramientas. La gente parece enloquecer por cómo podríamos hacer frente a la situación hipotética en la que nuestras herramientas fueron retiradas repentinamente. Existía el mismo argumento sobre permitir que las calculadoras ingresen a los exámenes.

La realidad es que las herramientas mejoran y mejoran cada vez más y más y cada año no hay ninguna razón por la que deba suponer que se quedará sin ellas. Y las herramientas son excelentes para hacer cosas repetitivas con un alto grado de calidad, lo que significa que podemos enfocar toda la fuerza de nuestros increíbles intelectos homo-sapien en las partes difíciles (e interesantes).

ReSharper es una increíble adición a Visual Studio. Mi compañía actual no tenía ReSharper cuando fui entrevistado, pero fui tan evangélico en mi entrevista que me compraron una copia cuando acepté el puesto, así como una para el desarrollador que me entrevistó. Ahora se está implementando en toda la empresa. Las buenas herramientas se amortizan en muy poco tiempo.

Entonces, para responder la pregunta: su dependencia de las herramientas puede causar una evaluación falsa de sus habilidades en una entrevista, pero siempre darán una evaluación correcta de las habilidades del entrevistador. Si una empresa no reconoce el valor del soporte de herramientas en su entrevista, debe mostrarles la luz. Y si todavía no lo ven, entonces me preocuparía mucho aceptar un puesto allí.