Buenas
En mi laburo surgio la opción para mi y a otros 3 compañeros para que empecemos a sumarnos como entrevistadores.
Se que tenemos un topic donde contamos lo que NO nos gusta que nos pase cuando nos entrevistan pero quería un topic donde contemos las experiencias de entrevistas pero siendo uno entrevistador. (creo que el buen Adriano sabe del tema, e imagino que brunodiaz está entrevistando gente también)

Que buscan ?
Que cosas tienen en cuenta para seguir o no el proceso ?
Buscan las cosas bien técnicas o se fijan mas que nada en la experiencia ?
Como balancean lo que surge de la entrevista para decidir "categorias ?" ? (en mi laburo se le hacen 2 entrevistas con 2 personas [3 si hay dudas] y se trata de consensuar la categoría)

Como soy de sistemas está bueno cosas orientada a eso aunque obvio se aceptan (y espero) consejos/experiencias entrevistando de otros rubros también.


Saludos!

Para mi, para la parte solo tecnica, no hay mejor forma de entrevistar a alguien que haciendo pair programming.

Despues, algun ejercicio para hacer desde la casa y cuya resolución sea más o menos libre. Para dridco me habian tomado uno de grafos que estaba muy piola. Les pedis que hagan un repositorio y ves los commits que va haciendo, si usa alguna metodología al desarrollar, etc.

Cuando entrevistaba yo, aparte del pair programming solia hacer un set de preguntas sobre actualidad en desarrollo para conocer mas o menos el perfil de la persona y que cosas les interesaba, además de preguntas sobre "Que opinas sobre X cosa?".

yo hago entrevistas tecnicas principalmente, pero nada de escribir codigo. Entre que nadie programa en papel, la situacion estresante de la entrevista y nadie en su sano juicio se sabe la sintaxis o el api de memoria es completamente al pedo.

Prefiero sentarme y hablar de sus proyectos viejos, que hizo y que no, como lo laburo antes y cosas mas importantes que te das cuenta cuando alguien bolacea y cuando no. Y aun asi si un 5% sean chantas y pasen igual, laburando con esa persona antes de los 3 meses te vas a dar cuenta que vendehumo es y lo hechas en su periodo de prueba.

(10-07-2015 22:44).py escribió:  laburando con esa persona antes de los 3 meses te vas a dar cuenta que vendehumo es y lo hechas en su periodo de prueba.

que fuerte jaja

uno de mis jefes intenta ver el interes en aprender del que va a entrevistar, por ejemplo le pregunta si conoce patrones de diseño y por lo general todos le dicen sisi, singleton y no le saben decir otro y para eso prefiere que le digan que no, de hecho el que termino entrando lo logro por ser sincero y decir que no los conocia y demostro interes en aprender.

yo creo que si tuviera que hacer una entrevista preguntaria sobre sus trabajos anteriores, trabajitos personales y algunas preguntas tecnicas

Ahora hace rato que no entrevisto... pero les dejo algunas cosas que tengo en mente...

Mi recomendación es que charlen con la persona en cuestion, y pasen un poco por todos los puntos que uds creen que esa persona deberia tener. Ya que de uds depende que esa persona entre o no a laburar y ademas con que nivel, les recomiendo que tengan alguna escala que les permita que lo que piensan sea medianamente objetivo. En nuestra epoca teniamos una lista de competencias a evaluar, y una lista de preguntas que fuimos armando entre todos los entrevistadores. Las preguntas las podes clasificar por seniority, y eso te puede ir dando la pauta de que onda la persona. Tener una pequeña lista de que deberia tener cada persona para ser jr, para ssr y para sr en cada "categoria" te ayuda a clasificar.


Algunos tips sueltos que me gusta tener en cuenta:

- Un jr deberia conocer medianamente el lenguaje en cuestion y poder codear tareas simples. Un ssr deberia poder codear tareas medianamente complejas, o bien bastante complejas por imitacion. Un sr deberia poder llevar un proyecto sin mayores problemas.
- Busca comportamiento del pasado para ver si lo puede repetir en el futuro. Un tipo que te dice que la tiene re clara con X cosa pero que apenas la uso, no es un SR en eso, aunque se venda re bien. Un tipo que nunca lidero un proyecto, no es un PL SSr, y asi. Pregunta muchas cosas... hay muchos charlatanes que te van a contar que implementaron una arquitectura saraza con tal y tal framework, y cuando los apuras un poco no tienen ni idea y te estan vendiendo humo. El tipo que sabe de que se trata, va a saber explicartelo. A veces pasa que la persona en cuestion te pasa el trapo en seniority y te habla de cosas que no tenes ni idea... todo bien, blanqueale que no sabes de eso y que te explique al respecto. Cuando termina la entrevista googlealo.
- Llevar una laptop con las preguntas y si es posible, un ejemplo chico de codigo. Las preguntas, para tenerlas a mano. Nunca ponerse a boludear con la compu mientras entrevistas, tampoco a contestar chats del laburo. Es super irrespetuoso. Avisar al principio como va a ser la entrevista y que tenes la maquina por las preguntas y porque vas a ir tomando notas de la entrevista.
- "Planifica la entrevista". A mi, particularmente, me gusta escuchar los primeros 10 minutos la experiencia de la persona sin preguntar nada (a lo sumo, alguna cosa para seguirle el hilo a la conversacion), despues pasar a preguntas relacionadas (me contaste que hicieron tal proyecto en 3 meses... ok, como lo estimaron? que metodologia usaron? que problemas tuvieron? quien diseño la arquitectura? como era? porque asi y no asa? etc), preguntas tecnicas mas generales, ver algo de codigo chico (que codee algo super chico tipo una funcion para saber si una palabra es un palindromo, otra que te calcule los primeros x terminos de fibonacci) y para cerrar, darle un toque al entrevistado para que nos cuenta algo que le gustaria que le hubiesemos preguntado y no lo hicimos.
- Usaba mucho este pedacito de codigo: http://ayende.com/blog/102402/negative-h...s-part-ii. Le pedia a la persona en cuestion que me dijera que le parecia (con la esperanza de que me dijera que es horrible) y le preguntaba que errores mas graves encontraba. Eso te ayuda a medir seniority tambien... es facil ver algunos errores pero dificil ver otros. Si les sirve esa parte, todo suyo... si no, pueden buscar otro ejemplo... hay miles
- Si pueden, entrevisten todos juntos. Hacerle 3 entrevistas tecnicas a un pibe es una patada ninja. El 80% de las preguntas se repiten. Uno (el mas sr quizas) va llevando la entrevista y el resto va acotando. No se pisen entre uds... a veces necesitas 3 o 4 preguntas para llegar a LA pregunta, y si te cambian de tema te queres matar.
- Decidan que onda el pibe un ratito despues de la entrevista. Si se toman 4 dias para evaluar a un pibe que esta buscando laburo, para cuando le dan el OK, ya lo llamaron de otro lado.
- Una vez que decidieron el seniority, fijense si para uds la persona es un SI o un NO. Si uds pondrian a esa persona a laburar en sus equipos sin dudarlo, es un SI. Si tienen dudas o lo ven mal, es un no. Importantisimo asi que lo repito. Si tienen dudas, es un no. Las empresas estan llenas de "parecia que iba a andar bien, pero al final era un chanta". Miren mucho la actitud... a veces tenes gente que es muy grosa tecnicamente, pero no te cierra la parte "humana". Si notan que la persona cambio de laburo demasiado seguido pregunten porque... a veces es un sintoma de que el candidato va a laburar 3 meses con uds y se va a ir. A veces de que es inquieto y que necesita desafios tecnicos todo el tiempo.
- Entrevisten y entrevisten. Con un poco de tiempo van a agarrar experiencia. Mas alla de todos los consejos que puedan leer.
- Esto es mas de gusto personal... Una anecdota al principio de la entrevista siempre suma y ayuda a entrar en confianza. Tengan un par preparadas sobre ese proyecto que salio perfecto, ese proyecto que estaba prendido fuego y apagaron, ese tipo groso que labura con uds, te mira el codigo y en 3 segundos te dice donde estaba el bug
- Este PPT esta muy bueno http://www.slideshare.net/yampolskiy/rec...asy-steps. Es una charla que dio un ex CTO de una empresa en la que labure un tiempo. Me recluto a mi, asi que algo sabe
- Una GRAN pregunta de cierre es "que me preguntarias para conocer mi seniority?". Eso que te pregunte, preguntaselo vos. Te da dos pautas en una sola pregunta .

Cualquier duda o pregunta que tengan avisen. Justo estoy armando un curso para entrevistadores a precio promocional para empresas (?)

(13-07-2015 00:25)Virus escribió:  

(10-07-2015 22:44).py escribió:  laburando con esa persona antes de los 3 meses te vas a dar cuenta que vendehumo es y lo hechas en su periodo de prueba.

que fuerte jaja

para eso esta el periodo de prueba.

Off-topic:

(10-07-2015 22:44).py escribió:  laburando con esa persona antes de los 3 meses te vas a dar cuenta que vendehumo es y lo hechas en su periodo de prueba.

hdp! sin H

ontopic: muy importante lo de "estar presente" en la entrevista. No hay nada mas molesto que ver al entrevistador mas concentrado en los mails/llamados que en la entrevista en sí.

Sobre esto: http://blog.triplebyte.com/three-hundred...hirty-days

muy buen artículo !
El tema es que, me da a mi la sensación, es que al no haber tanta oferta, poner tanta exigencia/restricciones termina haciendo que de por si consigas muy poca gente o ninguna.
Obviametne tampoco quiero caer a lo IBM y meter gente a lo pavo y negrear, pero se hace complicado encontrar un balance (creo yo) en las entrevistas y las barreras de entrada a un empleo.
O terminas metiendo a cualquiera, a riesgos de que algunos te salgan buenos y otros no, o no metes a nadie..

Eso es también un poco mi sensación en base a la gente que vi desfilar en las 2 empresas que laburé, puede que me equivoque

up porque hoy tengo mi primera entrevista

jamás hice una entrevista, pero opino igual:

Si vas a contratar un jr, las preguntas las haría para saber qué tipo de persona es, es decir, si se la ve motivada a aprender, a trabajar, o si es un lerdo que no aspira a nada. Tantear sobre qué conocimientos base tiene.

Si ya tiene experiencia, que hable de su experiencia. Un trabajo que le gustó cómo salió, un quilombo que tuvo inesperado y cómo lo resolvió, o una situación que no pudo resolver. Un laburo que le gustaría haberlo hecho de otra manera pero "salió así y quedó". Si es con una tecnología específica, que cuente cómo la utilizó, qué herramientas le sirvieron.

suerte gonza

igual como es la primera no la doy solo, voy a estar con uno de los habituales entrevistadores pero me gustaría preguntar algunas cosas y no simplemente "escuchar"

Gonnza yo hace un tiempo que entrevisto gente.
Me parece que no hay una unica forma de entrevistar. En mi caso me importa mas lo conceptual, la calidad de la persona, la forma que tiene de pensar, y que no me chamuye (en mi caso si me chamuyas ya te descarto).
Una vez que esa persona me cierra conceptualmente, me cierra como piensa, empiezo a hacer que me cuente un poco libremente de sus trabajos anteriores, en que proyectos participo, que rol cumplio, si trabajo en equipo, como se sintio, metodologias, control de versiones, ambientes, puestas en marchas, por que se fue de donde trabajaba.
Trato de que todo sea en un ambiente de confianza, ya que en definitiva vamos a trabajar de esa manera. Si todo esto me cierra, ahi y recien ahi le arranco a hacer preguntas tecnicas, por ultimo tenemos preparado un examen escrito, que mas que nada sirve para terminar de evaluar cuan chamuyero es.
En definitiva como dicen arriba, nadie prorama en papel y nadie se sabe toda la sintaxis de nada de memoria.

En resumen, todas las entrevistas son distintas, hay gente para todo. Esta bueno estar de este lado, sirve un monton. En mi experiencia tomando eso que te cuento como guia, siempre me alcanzo para darme cuenta si estoy frente a alguien que es un capo, a alguien que quiere aprender, a un chanta, o a un desastre...

Si buscas ejercicios, en mi laburo (buscan devs javascript) hacen este ejercicio:

 var i = 1;

var j = 10;



function execute(){

    console.log(i, j);

    if(true){

        var i = 0;

        var j = 1;

        console.log(i, j);

    }

    console.log(i, j);

}



execute();

console.log(i,j);

Y te preguntan que imprime en la consola. Es una locura la cantidad de personas que te dicen que el console.log de la linea 5 imprime "1 10", y que te mienten diciendo que laburaron (N>3) años en javascript.

Obviamente la mayor parte del tiempo la entrevista es sobre cuestiones mas orientadas al diseño (codigo & ux)... pero si un tipo dice que tiene experiencia en JS, y este ejercicio te lo hace mal, sabes que tenes que tomar con muuuchas pinzas las cosas que dice que sabe.

Nada mejor que tener su github/bitbucket/gitlab.

(03-08-2015 14:02)Imakuni escribió:  Si buscas ejercicios, en mi laburo (buscan devs javascript) hacen este ejercicio:

 var i = 1;

var j = 10;



function execute(){

    console.log(i, j);

    if(true){

        var i = 0;

        var j = 1;

        console.log(i, j);

    }

    console.log(i, j);

}



execute();

console.log(i,j);

Compilar y ejecutar código

Y te preguntan que imprime en la consola. Es una locura la cantidad de personas que te dicen que el console.log de la linea 5 imprime "1 10", y que te mienten diciendo que laburaron (N>3) años en javascript.

Obviamente la mayor parte del tiempo la entrevista es sobre cuestiones mas orientadas al diseño (codigo & ux)... pero si un tipo dice que tiene experiencia en JS, y este ejercicio te lo hace mal, sabes que tenes que tomar con muuuchas pinzas las cosas que dice que sabe.

Nada mejor que tener su github/bitbucket/gitlab.

Genial ese extracto de código, sencillo y al pie.

Y tener un github con código propio es la ideal, (imagino que) suma bastante.