¿Cómo realizar una entrevista para un tema en el que no soy muy bueno?

Actualmente estoy trabajando para una pequeña empresa como desarrollador de software/sitio web. Principalmente escribo el código del lado del servidor; las interfaces que creo para el sitio web son suaves y realmente no interactúan con el usuario.

Traté de aprender JavaScript, J-Query y Ajax pero me pareció demasiado porque rara vez tenía tiempo para otra cosa.

Mi empresa decidió contratar a algunos desarrolladores del lado del cliente que pueden escribir el código del lado del cliente. Vamos a realizar una entrevista cara a cara en unos 3 días con los entrevistados.

El problema es que no hay nadie que sea bueno en eso, así que me pidieron que probara las habilidades técnicas de los entrevistados.

Lo único en lo que soy bueno es en los conceptos básicos de JavaScript. No creo que los entrevistados tengan ningún problema en responder a las preguntas que les planteo, ya que se trata de un guión básico.

¿Cómo puedo entrevistar mejor a las personas cuando no tengo las habilidades necesarias para determinar si podrán realizar el trabajo?

Respuestas (5)

A veces me han llevado a entrevistas para puestos en los que no estoy particularmente capacitado y, como especialista, a menudo me han entrevistado personas que no conocen muy bien mi área. Aquí hay cosas que he visto funcionar:

  • Antes de entrevistar a alguien, intente aprender las cosas "101" en el área relevante. Para Javascript, hay una variedad de recursos en línea. Nota: esto no es para que puedas hacer buenas preguntas; probablemente no lo harás. El propósito de esto es que puedas detectar BS.

  • Haga preguntas de comportamiento que los hagan hablar sobre los problemas técnicos. "¿Cuál fue el error más difícil que tuviste que resolver?" es bueno; puede pedirles que expliquen cuál fue el problema, qué enfoques tomaron, qué hicieron finalmente, etc. Esto puede o no informarle directamente sobre la calidad de su código, pero le dirá mucho sobre cómo analizan, desglosan y, en última instancia, resuelven problemas. Y si dejan caer los detalles de implementación, puede tomar notas y tal vez hacer una verificación de cordura más tarde.

  • Pídales que hablen con cierto detalle sobre un proyecto importante: arquitectura, diseño, consideraciones de UX, pruebas, implementación, mantenimiento, etc. Casi no importa en qué idioma esté el código para la mayor parte de esto; está tratando de responder a la pregunta más profunda de "¿puede esta persona escribir software con el que querremos vivir?".

  • Solicite una demostración. Elija algo interesante y solicite un recorrido por el código detrás de él. A medida que el candidato explica lo que hace, debe buscar las cosas habituales de higiene del código: comentarios, organización clara, nombres comprensibles, etc. Si se esfuerza por explicarlo, eso es motivo de preocupación. (Una mirada rápida al código y "oh sí, ahí es donde puse eso" está bien; quiero decir, si está perplejo).

  • Asegúrese de obtener referencias técnicas, no solo gerenciales, y pregúnteles acerca de las fortalezas y debilidades técnicas del candidato.

Hago más o menos lo mismo, otra que considero casi obligatoria es pedirles que me expliquen algo que no sé, "simplemente cubran los conceptos básicos de qué es la tecnología X y cuándo es más útil", si no pueden hacer esto en un corto período de tiempo y de una manera comprensible, esto no es una buena opción. Particularmente cuando su equipo aún no tiene un experto, es mejor que cualquier "experto" que contrate pueda explicar a los no expertos algunos conceptos simples para que pueda interactuar con éxito.
@bethlakshmi, ese es un punto excelente; quienquiera que sea contratado para este puesto necesitará poder explicar sus decisiones de diseño/implementación de manera que todos los demás puedan entender, lo suficientemente bien como para que puedan hacer preguntas relevantes y obtener respuestas.
sí. El peor error que cometí fue contratar a un tipo que parecía tener sentido para otros expertos, pero que no tenía sentido para mí, el no experto. Resultó que el tipo era inteligente, pero muy malo para comunicarse, por lo que hizo cosas complicadas que no sirvieron pero que funcionaron perfectamente dentro de sus propias suposiciones defectuosas.
Ahora todavía estoy tratando de recordar cuál fue el peor error que encontré... los causados ​​por el infame PHP #29992 podrían ganar, pero no estoy seguro.
Vaya respuesta. Solo desearía que todavía estuvieras aquí para apreciar mi voto a favor :-/

Le recomiendo que incorpore los fundamentos del desarrollo de software en su estrategia de entrevistas. Como disciplina, independientemente del idioma, existen varias preocupaciones que afectan al desarrollo/ingeniería de software:

  • Patrones de diseño : un proyecto decente utilizará algún tipo de patrón de diseño. Un desarrollador decente debería poder identificar un patrón específico y debe haberlo implementado en algún momento reciente en el pasado. Yo mismo no soy un ninja de javascript, pero puedo arriesgarme a suponer que con marcos como Node.js, un desarrollador de javascript experimentado tendría una comprensión de los principios básicos de diseño de software.

  • Rendimiento : sin importar el idioma o la plataforma, generalmente hay una manera eficiente de hacer las cosas y una forma derrochadora de hacer algo. En Java, existe la BufferedXXXfamilia de clases destinadas a una mejor programación de E/S y cualquier desarrollador de Java con 6 meses de experiencia lo sabrá. Busque principios de rendimiento tan fundamentales en JavaScript que un desarrollador experimentado debería conocer. Echa un vistazo a este artículo para obtener orientación.

  • Marcos : como corolario del primer punto, puede buscar uno o dos marcos de JavaScript y hojear la introducción (particularmente lo que estos marcos pueden lograr). Ahora diseñe una o dos preguntas de la entrevista en torno a eso. El objetivo aquí es simple: el entrevistado ha usado estos marcos antes y puede demostrar un nivel de comodidad que supera el suyo propio O no ha usado el marco en cuestión PERO la persona debería poder proporcionar alternativas a los marcos y lo que puede lograr

  • Problema de trabajo : investigue a fondo un problema específico en javascript (puede comenzar mirando una de las preguntas de javascript más votadas en SO), comprenda la solución y presente este problema al entrevistado. Podría ser una pregunta básica sobre cómo codificar o una más conceptual sobre las mejores prácticas. La conclusión es que debe saber la respuesta y por qué es la respuesta (en caso de que el entrevistado esté equivocado o proporcione un enfoque alternativo)

En última instancia, lo que desea en un desarrollador es flexibilidad e inteligencia, subproductos de una sólida comprensión de los fundamentos del desarrollo de software.

Probablemente sea una buena idea preguntarles algunas de las cosas 101 y ver cómo les va de todos modos; esperaría que respondieran con bastante confianza, pero estoy seguro de que algunos no lo harán.

También trataría de pensar en un escenario real en el que puedan trabajar en su empresa y les preguntaría qué enfoque tomarían para resolver el problema; luego, investigue el problema usted mismo o tal vez haga la misma pregunta en la pila o en otro tablero de mensajes y ver si su respuesta tiene sus méritos.

Recuerde siempre tener personal en un período de prueba en el que pueda deshacerse de ellos si no encajan bien. A veces no se trata de tener el mejor programador absoluto, sino alguien que esté dispuesto a aprender más y que trabaje bien en equipo.

Creo que la mayoría de los entrevistados estarán nerviosos y pensarán que hay un truco oculto en las 101 preguntas. Entonces comenzarán a pensar demasiado en ello y flaquearán :)

Les pido a los desarrolladores que codifiquen frente a mí. Idealmente sé el idioma, pero aceptaré algo donde no lo sé. Si sé de antemano que no conozco el idioma, miro los detalles/API relevantes con anticipación para saber qué esperar. También intentaré hacer preguntas sobre los aspectos de la tecnología que conozco. Si no sé de antemano cuál será el idioma (un pasante sabe algunos idiomas y no se superponen con el mío), está bien. Todavía puedo verificar la lógica al ver el código y mirarlo con más detalle más adelante si quiero.

Para JavaScript, podría tener el código candidato en una computadora frente a usted. Verás qué bibliotecas usa la persona, cómo piensa, investiga, pregunta sobre requisitos, etc.

Como dijiste, te importa que el candidato pueda hacer el trabajo. Entonces, ¿por qué no darles algo similar al trabajo? No el trabajo real porque eso sería como obtener mano de obra gratis. Pero un ejemplo inventado que usa habilidades similares.

Algunos pueden pensar que esto no responde a su pregunta, pero creo que ofrece algunas estrategias para resolver el problema de contratar a un desarrollador calificado del lado del cliente. ¿Hay alguna ley que diga que tienes que hacerlo tú mismo?

  1. Trabaja en los detalles para este trabajo. Escribir código del lado del cliente y UX no es lo mismo. Es posible que desee un poco de ambos, pero decida la proporción. Este es el primer paso para conseguir a la persona adecuada para el trabajo. Hay muchos desarrolladores que aprenden javascript, CSS y html, pero no pudieron diseñar un símbolo del sistema.
  2. Obtenga ejemplos de su trabajo.
  3. Contratar a un contratista a tiempo parcial. Si comete un error de contratación, puede corregirlo fácilmente deshaciéndose de la persona por mucho menos que un empleado a tiempo completo.
  4. Como opción al n.° 3, utilice una agencia de contratación. Puede crear una situación de contratación temporal si desea obtener un poco de libertad. Muchas personas pueden cuestionar la capacidad de algunas de estas agencias para identificar el talento técnico. Algunos de mejor que otros.
  5. Póngase en contacto con personas en su tecnología. comunidad y tratar de obtener algunas recomendaciones. ¿Por qué esperar y ver quién se postula?

Como parte del proceso de la entrevista, concentre algunas de las preguntas en las áreas problemáticas que ha tenido. Póngalos en el tablero para simular algunos diagramas y códigos, pero idealmente colóquelos frente a un teclado y vea lo que tienen. ¿Pueden escribir código? Vea qué herramientas utilizan. ¿Traen problemas de compatibilidad con el navegador? ¿Han visto problemas similares? Estaba incursionando en un front-end web y conocí a alguien en una cafetería que fue capaz de deslumbrarme en menos de 15 minutos. Contrataría a esta persona en el acto.