¿Cuál es la mejor manera de evaluar a los nuevos programadores? [cerrado]


52

¿Cuál es la mejor manera de evaluar a los mejores candidatos para conseguir un nuevo trabajo (hablando simplemente en términos de habilidades de programación)? En mi compañía hemos tenido muchas malas experiencias con personas que tienen buenas calificaciones pero que no tienen habilidades de programación reales. Sus habilidades son simplemente como monos de código, sin la capacidad de analizar los problemas y encontrar soluciones.

Más cosas que tengo que tener en cuenta:

  • El sistema educativo en mi país apesta, realmente apesta. Las personas que son buenas en este tipo de trabajo son buenas porque tienen talento o realmente intentan aprender por su cuenta.

  • El título universitario / posgrado / posgrado no significa necesariamente que sepa exactamente cómo hacer las cosas.

  • Las certificaciones tampoco significan nada aquí porque las personas a cargo del curso de certificación tampoco tienen habilidades (o están en trabajos mal remunerados).

Realmente necesitamos obtener buenos candidatos que sean flexibles y que no tengan un pensamiento mecánico (porque este tipo de personas por experiencia tienen un bajo rendimiento).

Estamos en una institución gubernamental y las personas que son candidatas no necesariamente provienen del exterior, pero tenemos la posibilidad de aceptar o no candidatos hasta que encontremos la correcta.

Espero no sonar demasiado agresivo en mi pregunta; y por cierto yo mismo soy programador.

editar: descubrí que preguntaba algo realmente complejo aquí. Desactivaré "la respuesta correcta" solo para dejar que la discusión fluya sin ningún sesgo.


Valoro la creatividad, como tú dices con respecto al código monkeying No me gusta el enfoque de la fuerza bruta, si generaciones de programadores anteriores han utilizado un enfoque dado, podría significar que es genial, o simplemente que se ha perpetuado durante mucho tiempo. Tampoco se supone que la educación se centre en las habilidades comerciales, y yo diría que es súper importante, pero coloca las calificaciones reales adquiridas más allá de un nivel competente básico como no tan importantes. Me encantaría ver más de un sistema de estilo de la Academia Khan de muchos módulos pequeños de pasa / falla con otras dependencias de pase de módulo y un período de enfriamiento antes de poder volver a tomar un módulo.
alan2here

Respuestas:


52

Con respecto a la selección de candidatos, generalmente sigo un plan de tres golpes:

  • Prueba regular con preguntas de codificación tipo FizzBuzz y muchas preguntas de conocimiento en las que tienen que dar ejemplos codificados. Dependiendo de la posición, pueden ser principios de OO, principios de diseño de SQL, etc. Incremento las dificultades de las preguntas en la prueba para ver hasta dónde pueden llegar. La idea no es realmente tener todas las preguntas respondidas (si es así, mejor), sino también ver si pueden reconocer cuando no saben algo. La confianza es esencial, y no quiero que alguien me mienta en mi equipo.

  • Regrese a la prueba con el candidato y discuta las respuestas. Posible extensión de las preguntas para alcanzar los límites del candidato. Esto puede ser extenso, y cuanto más extenso sea, mejor.

  • Última parte, pero no menos importante, The Code Review . Le pido al candidato que traiga un fragmento de código (generalmente espacio la prueba / discusión anterior y esta revisión unos días, para que pueda escribir y pulir un fragmento de código). Luego hacemos una revisión regular del código con dos personas: una persona que trabajará directamente con el candidato y la persona que revisó la prueba con el candidato previamente. Con respecto a la revisión del código, puede leer este artículo de JohnFX .

Al final de todo esto, debería poder decidir si desea que este candidato forme parte de su equipo o no.


44
Estoy de acuerdo con las preguntas de codificación y de conocimiento, nunca estuve de acuerdo en pedirles a los candidatos que traigan un código. En mi opinión, no es fácil encontrar un código sustancial que: muestre algo no trivial, no requiera demasiado conocimiento de un sistema más grande y que se le permita mostrar a otros.
Andrea Zilio

Yo diría revisión de código. FizzBuzz está tan sobreutilizado. Y podrías asustar a la gente. He sido programador en atención médica y servicios financieros, y cosas como fizzbuzz son inútiles. Debes poder entender una interacción mucho más complicada. Pídales muestras de código, incluso si es un FPS en pygame. Si no tienen ejemplos de código, no son codificadores.
Christopher Mahan

1
@ChristopherMahan El valor de FizzBuzz (y una codificación trivial similar) es como un simple portero. Si no pueden implementar FizzBuzz, en su idioma de elección, ¿pueden escribir CUALQUIER código?
Vatine

@Vatine FizzBuzz prueba la capacidad de razonamiento lógico, no la habilidad de programación. Por supuesto, uno debería poder hacerlo. Una simple pregunta de programación sería: mostrar en pantalla una lista de elementos ordenados de manera interesante. Tendrían que codificar, pero podrían recurrir a la experiencia para encontrar algo para escribir, y no tener que tratar también de descifrar el desafío para la mente. Una vez fallé una entrevista porque querían que usara expresiones regulares y respondí que para ese problema, la expresión regular es una exageración y Python tiene capacidades incorporadas para hacerlo. No quería trabajar allí, supongo.
Christopher Mahan

La revisión de código es una idea terrible, y la refutación de JohnFX es insuficiente. Conozco a muchos desarrolladores que son geniales, pero que no trabajan en nada fuera de las bases de código de propiedad de su empleador. Estas son personas con familias y cosas que hacer fuera del trabajo. Sin embargo, cuando trabajan, son muy productivos.
MrFox

20

Comienza dándoles FizzBuzz para que resuelvan. Eso debería eliminar a los peores de ellos.

Luego, algo un poco más difícil, por ejemplo, cómo invertir una cadena sin funciones de biblioteca incorporadas. Pídales que hablen mientras resuelven para ver cuál es su proceso de pensamiento.

Puede seguir dando problemas más difíciles si los encuentra muy fáciles, hasta que esté convencido de que pueden caminar y no solo hablar.


1
Supongo que puede depender del nivel de programador que estés entrevistando. Si bien podría estar bien acceder a la capacidad de un empleado de nivel junior, consideraría que tales preguntas en una entrevista son un claro indicador de que esta no era una empresa en la que quería trabajar.
jfrankcarr

3
No estoy de acuerdo con la parte que habla. ¿Hablas a menudo contigo mismo o con otras personas mientras resuelves problemas? ¿Qué tal si le damos espacio a una persona y le permitimos pensar un poco? Entonces, a menos que sea completamente trivial, creo que no es una buena práctica.
Andrey Rubshtein

1
@Andrey: la parte que habla es obtener una idea de su proceso de pensamiento. Desea ver cómo piensan sobre un problema y cómo lo resuelven. ¿Tienes una mejor opción?
Oded

55
@Oded, sí, de hecho lo hago. Déjelos pensar un rato, solos , como lo harían en la vida real, especialmente si es un problema difícil, y luego pregúnteles todo lo que quiera. Como en cualquier examen oral.
Andrey Rubshtein

44
Incluso como asistente en una escuela que tiene varios profesionales de CS recientemente reconocidos, encuentro que el fizzbuzz trivial es un buen filtro. La mayoría de las personas con las que me gradué probablemente no pudieron resolverlo en un tiempo razonable. Esas personas lucharon por encontrar empleo o no. Creo que seguir joelonsoftware.com/articles/GuerrillaInterviewing3.html es bueno.
Plataforma

14

Solo busca pasión por el trabajo.

Para citar a Joel, busque personas que sean " inteligentes " y haga las cosas " .

El resto no importa


77
El problema es que no puedes saber si son inteligentes.

44
@Chad: la pasión por el aprendizaje no "hace las cosas". Para saber si alguien puede hacer las cosas, debe pedirles que hagan algo.
Kevin Cline

2
@kevin cline, modificó mi publicación. Necesitan tener pasión por el trabajo, generalmente eso se demuestra al querer aprender. Sí, toma algunas preguntas, la conversación debería fluir, no debería ser solo una serie de preguntas. Pero para averiguar si logran hacer las cosas, pida ejemplos de dónde tuvieron un obstáculo y cómo lo superaron. Todos se topan con obstáculos en su trabajo, ya sea desde la tecnología, las personas, los procesos, pero una persona inteligente, que hace las cosas, encontrará la manera de superarlo y podrá explicarlo, en detalle, lo suficiente como para venderlo. sus abilidades.
CaffGeek

3
@mouviciel no en mi experiencia. Algunos de los programadores más inteligentes que conozco son muy extrovertidos.

44
Si no puede sentarse en una habitación con un candidato desarrollador y averiguar si son inteligentes o no, busque a alguien que pueda hacerlo.
JeffO

13

Basado en mis 25 años de programación (que, ciertamente, incluye solo 5 o 6 instancias de contratación de otros programadores):

Indicadores positivos:

  • Apasionado por la tecnología.

  • Programas como hobby

  • Hablará en voz alta sobre un tema técnico si se le anima

  • Proyectos paralelos personales significativos (y a menudo numerosos) a lo largo de los años

  • Aprende nuevas tecnologías por su cuenta.

  • Opinión sobre qué tecnologías son mejores para varios usos

  • Muy incómodo con la idea de trabajar con una tecnología que no cree que sea "correcta"

  • Claramente inteligente, puede tener excelentes conversaciones sobre una variedad de temas

  • Comenzó a programar mucho antes de la universidad / trabajo

  • Tiene algunos "icebergs" ocultos, grandes proyectos personales bajo el radar CV

  • Conocimiento de una gran variedad de tecnologías no relacionadas (puede no estar en CV)

Indicadores negativos:

  • La programación es un trabajo diario.

  • Realmente no quiero "hablar de compras", incluso cuando se me anima a

  • Aprende nuevas tecnologías en cursos patrocinados por la empresa.

  • Feliz de trabajar con cualquier tecnología que haya elegido, "todas las tecnologías son buenas"

  • No parece demasiado inteligente

  • Comenzó a programar en la universidad

  • Toda la experiencia de programación está en el CV

  • Centrado principalmente en una o dos pilas de tecnología (por ejemplo, todo lo relacionado con el desarrollo de una aplicación Java), sin experiencia fuera de ella

Además, sugeriría:

  • La prueba FizzBuzz (o algo así para probar la capacidad básica de escribir un algoritmo).
  • Versión más difícil de la prueba FizzBuzz (para llevarlos al punto de falla o casi falla).
  • Discuta su código y vea si están dispuestos a ser autocríticos y busque mejoras (que probablemente no tuvieron tiempo de hacer en una prueba corta en el acto) como:
    • buenos nombres de variables (he tenido codificadores muy experimentados que usan variables en producción como "flag" (WTF ??)
    • modularización
    • Anticipando problemas y haciendo "codificación defensiva"
  • La voluntad de ver los "defectos" como oportunidades de mejora. Creo que los mejores programadores siempre buscan fallas inquebrantables en su código anterior. No son tan egocéntricos como para pensar que encontrar un defecto es una afrenta personal. Lo ven como una oportunidad para hacerlo mejor. (Aquellos que no pueden ver los defectos sin pestañear se ven abrumados al ver un defecto (y se vuelven súper desconfiados o, para evitar eso, ignoran los defectos.
  • ¿Pueden depurar?
  • ¿Pueden la prueba de unidad? (He hablado con demasiados programadores que dicen "QC hace eso". No estoy hablando de pruebas, estoy hablando de pruebas: usted escribe una función, ¿funciona? ¿Hace esfuerzos razonables para tratar con problemas probables (entrada NULL, etc.) Si no puede hacer eso, ¿cómo sabe cuándo ha terminado?
  • ¿Tienen buenas habilidades de comunicación? (como mínimo: buena comprensión y autoconocimiento sobre cuándo entienden y no entienden y la voluntad de decir "No entiendo, explíquelo de nuevo".

Gran parte del resumen anterior es de Cómo detectar un buen programador , que es un gran artículo, centrado un poco más en los indicadores de mayor alcance. Definitivamente confirma mis intuiciones y experiencia. También hay muchas cosas (como "pasión") que normalmente no se mencionan en una lista de verificación de "qué es un buen programador".


10

La evaluación de la inteligencia de programación es una forma de prueba de Turing. Por lo tanto, (actualmente) no hay procedimientos de evaluación de forma cerrada que garanticen su funcionamiento. Se necesitan programadores inteligentes para reconocer a otros programadores inteligentes, pero solo con alguna probabilidad razonable.

Sus posibilidades serán mejores si tiene entrevistadores en su equipo que pueden oler trabajos de nieve, y instintivamente no les gusta trabajar con personas estúpidas (incluso aquellos que son guapos, tienen currículums vitales impresionantes y pueden arrojar todas las soluciones enlatadas habituales de memoria) .

(Una metodología de posibilidad que ayudaría a la calidad de stackoverflow como efecto secundario es desenterrar viejas preguntas de stackoverflow, relacionadas de alguna manera con los requisitos de su trabajo pero que en su opinión tienen respuestas inferiores; pregúntele al entrevistado cómo responderían, y pídales que lo publiquen si es una buena respuesta. Similar a una recapcha para OCR de origen público).


7

Dales un problema, preferiblemente uno asociado con el dominio del problema en el que estarán trabajando, y pídeles que discutan cómo lo abordarían. Puede hacer que solo discutan, pseudocódigo o escriban bits de código real dependiendo de qué tan seguro esté en su nivel de habilidad

Por ejemplo, si su organización realizó conferencias, pídales que describan cómo codificarían un sistema seguro de registro en línea. Deben poder cubrir algunos de los conceptos básicos y hacer buenas preguntas sobre exactamente lo que debe implementarse. A medida que interactúa, debe poder determinar si encajarán bien en su organización y el rol que necesita que desempeñen.

No soy un gran fanático de la programación de pruebas de trivia y enigmas. Si bien pueden ser divertidas para algunas personas, también pueden molestar y / o estresar a otras personas, incluidas las personas que podrían ser la mejor opción para su equipo. Además, la información sobre muchas de estas pruebas está disponible en línea y fomentará la acumulación de pruebas y otras tácticas que reducirían su viabilidad para medir la capacidad del programador.


Estoy de acuerdo con usted sobre las desventajas de la prueba de trivia / cerebro para la selección de candidatos. El problema es que revisar / discutir el código con cada candidato llevará demasiado tiempo. Y tal vez el resultado sería más subjetivo. no es exactamente lo que estoy buscando, preferiría algo que necesite menos supervisión personal. y más tarde, cuando tenga candidatos más adecuados, entonces hable / discuta / entreviste
Rafael

3
¿Demasiado tiempo? Alguien tendrá que hablar con los candidatos. Ninguna prueba escrita funcionará. El contenido de la prueba se convertirá rápidamente en conocimiento público y los candidatos llegarán con respuestas memorizadas.
Kevin Cline

10
@kevincline: Exactamente, tienes que hablar con ellos. Estaba entrevistando en Xerox (en los años 70) y me preguntaron cómo manejaría las colisiones en un algoritmo de hash. No tenía mucha educación formal en programación, pero lo había estado haciendo durante unos 5 años en ese momento, así que dije que no sabía qué era un hash. Mi entrevistador me lo explicó, luego volvió a hacer la pregunta. Continuamos durante más de una hora cuando descubrí y resolví varios tipos de problemas de colisión. Me dijo que si podía hacer eso en una hora, podría manejar cualquier cosa que me arrojaran. Conseguí el trabajo. Porque él me habló .
Peter Rowell

@PeterRowell Así es como deben ser las cosas. +1
Chiron

3

Leer esta pregunta y algunas de las respuestas que recibió me impulsaron a escribir un artículo que creo podría ser de interés:

Prácticas de reclutamiento extrañas al contratar desarrolladores de software

Ok, entonces el título del artículo es basura, pero el artículo llega al corazón del problema. No es problema del candidato que hayas elegido entrevistarlos, sin importar cuán inapropiados sean para el papel que tienes en mente. Si no ha logrado definir un procedimiento de contratación bien factorizado que le permita encontrar las gemas en bruto, entonces tendrá que vivir con las consecuencias, y sí, esto significa obtener algunos candidatos que podrían Nunca cumpla con sus expectativas. Filtrar a sus candidatos en función de sus cartas y currículums requiere que primero, pida a sus solicitantes que escriban una carta sobre ellos y lo que quieren del rol, y luego mire cómo se escribe el currículum. Si solo tiene uno o dos candidatos potenciales para entrevistar, entonces probablemente haya realizado la preselección correctamente.

Cuando eventualmente encuentre a los 1 o 2 candidatos que considera que realmente valen su tiempo, no haga simplemente un puñado de preguntas inútiles, sino que invierta el tiempo para conocer a estas personas y participar en debates abiertos sobre el software. ingeniería en general. Aprenderá más de un enfoque informal sobre el candidato de lo que nunca lo hará en la situación de entrevista tradicional (y algo conflictiva). Además, no se conforme con una sola entrevista, sino que invite a sus candidatos clave a varias reuniones donde se use una discusión abierta y donde el candidato pueda reunirse con sus posibles colegas. El tiempo nunca se pierde, ya que los candidatos inapropiados no prosperarán muy bien en una discusión altamente técnica, y mostrarán sus defectos muy rápidamente cuando bajen la guardia.


Buenos puntos. Sin embargo, tendría cuidado con demasiadas entrevistas. Tanto el candidato como su tiempo son valiosos (especialmente si el candidato está actualmente empleado en otro lugar). En mi experiencia, cada vez más entrevistas tienen rendimientos decrecientes, por lo que me limitaría a una o dos entrevistas. Una entrevista telefónica (adicional) también podría ser un compromiso.
sleske

1
@sleske, estoy de acuerdo en principio, particularmente si las mismas personas asisten a todas las entrevistas. Por lo tanto, es mejor compartir la carga para encontrar la mejor opción tanto para la empresa como para el equipo, y le brinda la oportunidad de aprender de las observaciones de los demás. Las malas entrevistas no irán más allá, pero cuantos más interesados ​​estén interesados ​​en el candidato, más entrevistas necesitará, por lo que no es inusual tener 3 o incluso 4 entrevistas en equipos muy amplios. Sin embargo, muchos más darían la impresión de estar terriblemente desorganizado. También vale la pena decirle al candidato sobre el número de entrevistas por adelantado.
S.Robins

@ s-robins opiniones interesantes, solo quiero poner algo de luz sobre algunos aspectos de mi pregunta. Debido a una razón fuera de nuestro control, no podemos seleccionar a nuestros candidatos en base a un proceso de reclutamiento normal, en cambio, los candidatos solo vienen y debemos decir si él / ella tiene las habilidades / conocimientos correctos para tomar el trabajo. Quizás en un proceso de reclutamiento normal, estas cosas no suceden con demasiada frecuencia. pero en nuestra posición necesitamos lidiar con esta situación.
Rafael

@Rafael, si entiendo tus comentarios correctamente, estás diciendo que te alimentan los candidatos de "otro lugar" para evaluar y que tu dificultad es hacer una evaluación objetiva de un candidato sin conocimiento previo sobre ese candidato. Esto suena más como un problema sistémico dentro de la organización donde trabaja. Sugeriría reunirse con las personas que envían candidatos a su manera, y trabajar con ellos para diseñar un sistema para filtrar a los candidatos obviamente inapropiados antes de entrevistarlos. Quizás incluso solicitar que se implemente un proceso de solicitud más formal.
S.Robins

@ s-robins que entendiste bien ...
Rafael

1

No ha dicho para qué idioma, pero es bastante fácil evaluar el conocimiento de alguien. También depende del nivel que esté buscando, pero hay un grupo bastante grande de preguntas con respecto a las preguntas de la entrevista.

Independientemente de cómo decida celebrar su entrevista, no haga esas preguntas de entrevista de "rompecabezas de pensamiento lateral" .


2
propoly no he especificado el lenguaje que estamos utilizando para desarrollar, porque creemos que un buen programador (con su respetuoso curso de capacitación) puede aprender a programar en cualquier idioma independientemente de su sintaxis.
Rafael

2
@Rafael norvig.com/21-days.html . Como dije, depende si está buscando un programador junior o uno senior.
Bћовић

Porque estoy hablando de que la mayoría de los candidatos son recién graduados. Me refiero a los programadores junior, pero mi pregunta va en un contexto más amplio que mi proceso de reclutamiento personal específico
Rafael

@Rafael En ese caso, esperas demasiado de un junior. Lea el artículo que publiqué en el comentario anterior, donde dice cuánto tiempo lleva dominar un lenguaje de programación.
Bћовић

No estoy hablando de dominar un lenguaje de programación específico, estoy hablando de conseguir la mejor persona con el mejor conjunto de habilidades de programación genéricas, (por eso no especifico el idioma), no puedo esperar que todos eso viene como candidato a dominar el lenguaje que estamos programando, y es por eso que estamos en condiciones de impartir un curso de capacitación si las personas no conocen el idioma.
Rafael

1

Le sugiero que vaya con una pregunta de FizzBuzz y contrate la primera que pase. Las pruebas adicionales tienden a ser defectuosas, ya que no todo buen programador abordará un problema como usted, o manejará una entrevista sin tartamudear, o sabrá los idiomas que desea o le importan o tonterías como intercambiar enteros sin una tercera variable (¿quién necesita eso de todos modos? es decir, ¿desde que la RAM excedió los 128 bytes?).

Piénsalo. Si la pregunta de FizzBuzz elimina 199 de 200, entonces solo eliminó cientos de entrevistas. ¿Realmente ibas a entrevistar a cientos de prospectos?

Simplemente parece que los rendimientos disminuyen después de FizzBuzz. Eso supone que 199/200 está incluso aproximadamente cerca. Y supongo que TU tiempo también es valioso ...


2
Da miedo cómo FizzBuzz es la prueba estándar para evaluar la competencia de un programador. Sin embargo, esto es una prueba probado y verdadero - No puedo decir cuántos programadores con grados CS no pueden hacerlo (en su 'idioma de su elección')
Nodey El individuo Nodo

0

No estoy seguro de si esto es un comentario o respuesta, pero básicamente lo que dijo Matthieu. Desea preguntas estúpidas y fáciles que tardan uno o dos minutos (pero no más de 5) en hacerse y que deben ser sobre diferentes áreas.

Tales ejemplos de preguntas fáciles y estúpidas son preguntas sobre la recursividad, como tener una lista y debe imprimirla en orden inverso sin usar un bucle. Una simple pregunta sobre expresiones regulares si la expresión regular se realiza normalmente en su desarrollo. Una pregunta sobre bits y bytes si usa C ++ (escriba una plantilla que acepte char a long e imprima la representación binaria. No se requiere especialización, solo use sizeof () para calcular la longitud de bit)

Debería llevarte unos <= 3 minutos por pregunta


0

Pregúnteles sobre el desafío de programación más interesante que hayan intentado resolver pero que no pudieron, qué enfoque usaron mientras lo resolvieron, por qué no pudieron resolver y qué otro enfoque creen que puede resolver.

Esto es suficiente para juzgar las habilidades de un programador como programador.


0
  1. ¿Pueden defender lo que dicen saber? Lo pusieron en el currículum / CV como una habilidad o algo que hicieron en otro proyecto. Vea cuán en profundidad pueden llegar al tema.
  2. ¿Pueden aprender algo nuevo? Hable sobre un aspecto de alto nivel de la tecnología que está utilizando o sobre algo específico para el negocio en el que trabaja y vea si pueden comprender el tema. ¿Hacen preguntas inteligentes? ¿Pueden llegar a una analogía? ¿Es similar a algo que han hecho en otra industria o tecnología?

  3. ¿Prefieren estar programando? No tiene que ser el número uno en su lista, pero tienen que mostrar preferencia por escribir código. Y me refiero a escribir código y hacer algo, no sentarme y hablar sobre ello o dibujar en la pizarra todo el día. No para minimizar la planificación o para promover la codificación de vaqueros, pero eventualmente debes tener código. Evita a los que evitan el teclado. Esta no es una posición de gestión.

Puede hacer un puntaje en una escala de una a diez cosas o simplemente confiar en poder oler su propio tipo.


0

Si te hace sentir mejor, existen malos programadores en casi todos los países. Cómo eliminarlos es el problema.

El primer deshierbe es el currículum. Una cosa que busco es mucha experiencia lingüística y nada que describa lo que hicieron en ese idioma. He visto currículums que afirman que conocen todos los idiomas inventados y, sin embargo, su experiencia muestra que solo han trabajado con Access y Visual Basic. Esos van a la basura. Los currículums de 10 páginas van directamente a la basura (especialmente los currículums de diez páginas de personas con menos de 2 años de experiencia que he obtenido). De los graduados universitarios recientes con poca experiencia, debes ser muy exigente con la forma en que se presentan. Los mejores candidatos son cuidadosos con sus hojas de vida, no tienen errores. ¿Realmente estás buscando a alguien a quien le importe tan poco que no se molestó en revisar su currículum?

Los currículums preparados profesionalmente también van a la basura. Una vez que haya leído cientos de currículums, puede elegirlos ya que usan exactamente la misma redacción. No puede confiar en el contenido de un currículum profesionalmente preparado y sabe que la persona no hizo su propia preparación. Este es el tipo de persona que dependerá de otros para resolver sus problemas por él, ¿realmente quieres eso en una posición de programación?

Busque cosas que hagan que la persona se destaque por las que elija. Eso es más difícil, por supuesto, con los que acaban de salir de la escuela, pero busca logros, contribuciones al código abierto, etc.

La próxima eliminación es la entrevista telefónica. Pregunte acerca de los conceptos básicos que se relacionan con el trabajo real que tiene. Si las personas no tienen un conocimiento básico de los conceptos que necesita que tengan, no vale la pena molestarse en llevarlas a una entrevista personal. Los jóvenes a menudo piensan que esto es injusto porque pueden buscar todo en Internet, pero la verdad es que nunca he conocido a un buen programador que haya tenido que buscar todo en Internet. Debe tener algún conocimiento de su profesión que no tiene que buscar cada vez.

Después de la entrevista telefónica, debe elegir los mejores 4-5 candidatos y la entrevista. Por supuesto, si solo tiene 1-2 buenos candidatos, no se moleste en entrevistar a las personas que ya eliminó. Ahora hará las preguntas difíciles y tendrá una idea de cómo abordan los problemas. Nunca usaría la prueba de fizzbuzz porque es demasiado conocida, por lo que las respuestas no te dicen nada. En cambio, invente algunos problemas de su propia base de código. Podría darles un requisito y un fragmento de código y preguntarles si el código cumple con el requisito y si no, por qué no y qué podrían hacer para que cumpla con el requisito. Les pediría que describieran el problema de programación más difícil que tuvieron que resolver y qué pasos tomaron para encontrar la respuesta. Haría algunas preguntas técnicas más profundas. Recuerde que está tratando de tener una idea de su competencia técnica, su capacidad de resolución de problemas y depuración y su capacidad para adaptarse a su equipo actual. También hago preguntas que probablemente no saben la respuesta para juzgar qué tan bien manejan el estrés, es un trabajo estresante, no quiero a alguien que abandone la entrevista porque el estrés del trabajo es mayor que el estrés de la entrevista. . Busco fortalezas en áreas en las que actualmente somos débiles y la capacidad de trabajar en equipos y presentarnos a los clientes (nuestros desarrolladores tratan ampliamente con los usuarios), su lista puede ser diferente. No quiero a alguien que abandone la entrevista porque el estrés del trabajo es mayor que el estrés de la entrevista. Busco fortalezas en áreas en las que actualmente somos débiles y la capacidad de trabajar en equipos y presentarnos a los clientes (nuestros desarrolladores tratan ampliamente con los usuarios), su lista puede ser diferente. No quiero a alguien que abandone la entrevista porque el estrés del trabajo es mayor que el estrés de la entrevista. Busco fortalezas en áreas en las que actualmente somos débiles y la capacidad de trabajar en equipos y presentarnos a los clientes (nuestros desarrolladores tratan ampliamente con los usuarios), su lista puede ser diferente.


-1

Los candidatos deben tener un problema del mundo real para resolver con la libertad de usar cualquier tecnología.

Si ella sale a toda velocidad, ¡está dentro!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.