Los que trabajáis con Python... supongo que no haceis dependency injection, no? algo tan básico que hasta JS tiene 
#31438 terminando ingenieria informatica encontré un currillo en soporte técnico, cuando se fue el sysadmin que había que era un inútil pasé yo a sysadmin, pero como casi todos los programadores de la empresa eran Electrónicos o por el estilo (se dedicaban a programar PLC's y robots) casi todas las cosas de programación por derecho al final las acababa haciendo yo (y encima todo en C, todo maravilloso). Al final estaba echando mas horas que un tonto haciendo de todo, administrar sistemas, resolver incidencias, hacer pedidos de material informático, programar, dar soporte externo a clientes... y me he ido de la empresa en cuanto me ha surgido otra oportunidad.
#31441 en principio poca cosa, limpiar y documentar codigo de un software para formación de personal en empresas de montaje, luego ya se supone que pasare a hacerle unas pocas mejoras y ampliaciones y ya de ahí a donde el viento me lleve.
#31445 Cadiz. La verdad que me ha sorprendido bastante ver una empresa por esta zona que trabaje con esas tecnologías.
#31448 En un principio solo necesito hacer pruebas para ver si me funciona xDD
La idea es que, cuando detecte cambios en github, realice los tests en deployhq y, si no fallan, haga el deploy automático
#31449 soy la puta del dev, lo que me echen.
#31450 el autodeploy se puede hacer sin problema, de la rama que quieras.
#31451 sí, y no me gustó.
#31450 te amplío la info. En bitbucket puedes configurar webhooks hacia deployhq cuando se haga una acción sobre el repo
Y después en deployhq configuras el deploy automático
GG!
La entrega es hoy y nos está petando la aplicación por todos lados xd
Esto es lo que pasa al tener dos evolutivos tochos en diferentes ramas y juntarlas xd
Por lo menos la aplicación ahora compila
#31452 El autodeploy lo tengo listo desde hace varios meses y lo he usado en varios proyectos sin problema desde github y bitbucket como indicas 
aunque gracias por la info.
La idea es usar la funcionalidad de deployHQ de pipelines para que haga este proceso:
- DeployHQ detecta cambios en la rama del repositorio
- Obtiene los archivos
- Ejecuta los comandos que le indices (puede ser un composer install, composer update, o algo para pasar los tests)
- Si está OK, hace deploy a prod
- Si hace KO, te envía un email con el aviso
#31454 Usa jenkins.
En el job le agregas un bash step y ejecutas los test si no da OK ese step siempre falla y te manda el email con los detalles.
Si esta bien lo pasas a prod y a volar.
Me he leído este artículo por encimilla, habla sobre contratar senior devs. La prueba técnica es esta
https://drive.google.com/file/d/1PpJxlGrdS-19vqMrunDrTJaqMkQx8mgI/view
Y la tienen que pasar los candidatos en 2 horas. Creéis que vuestros compañeros senior hubiesen pasado una prueba así en el tiempo indicado? Y vosotros mismos? /discuss
#31457 poner tiempo a una prueba tecnica con tanto dominio por cubrir a mi me parece contraproducente.
Lo mejor es dejar al candidato hacer la prueba y que diga cuanto tiempo a invertido, tu como entrevistador debes saber cuanto es mucho/poco.
Yo en dos horas no creo, metiendo test y demas para la parte de PHP.
La primera parte de bases de datos si has hecho algo parecido en el pasado en 40 minutos te la puedes hacer, pero eso 2 horas a mi me parece poco.
#31459 en 2 horas está muy ajustado. La cosa es que dice arriba que "El objetivo es ver cómo gestionarías tu tiempo", igual la clave está ahí, y no en hacer todo.
Si tienes suerte y te sale todo rodado: la configuración del entorno, del proyecto, elección de un framework que hayas utilizado antes y te permita la máxima velocidad, tengas mucha experiencia con sql y bds relacionales... igual lo sacas, pero sin tests ni hostias.
También está la importación del csv con 1kk de registros, como no lo hayas hecho antes RIP.
#31460 El articulo de puta pena como esta escrito la verdad, pero en el tema de dar segundas oportunidades ahi coincido. Pero tambien su proceso es una puta mierda, porque eso de preguntar primer y mandar el test sin saber siquiera si es una persona que va a encajar es una perdida de tiempo para todo el mundo.
El test es el test, tu oportunidad de brillar, de demostrar todo lo que sabes hacer y esas cosas.
Ayer me llego un test php 5.6 procedural y un frontend que da ascopena con jquery y javascript ahi mezclado sin ton ni son, llamadas ajax que no comprueban si falla... ese tio no se merece una segunda oportunidad.
La unica razon que puedo aceptar para dejar re-hacer un test es que el candidato no lo haya entendido bien (porque nuestro supuesto es bastante vago para dejarte hacer lo que tu creas conveniente) pero nada mas.
Es que hacer un test tecnico para ver como gestionas el tiempo es un poco tonteria #31462, porque al final del dia ense;ar a alguien a ser mas eficiente y mejorar su planificacion es infinitamente mas facil y mas barato que tener a alguien que no puede resolverte problemas y cualquier programador senior que lleve trabajando 5 o 6 a;os sabe como organizar el tiempo.
Pues los 100k registros en un CSV para PHP hay pocas cosa para agilizar el proceso, si tienes un entorno que te permite hacer thread forking (suerte) puedes dividirlo y hacer la importancion en hilos paralelos, siempre y cuando la informacion mas abajo no sea dependiente de la de mas arriba.
#31463 el orden de los tests ya los discutimos en este hilo en el pasado. Depende.
A mí no me parece mal empezar cribando los que no lleguen a X habilidad como desarrollador. Visto desde tu otro punto de vista, si haces la entrevista personal y el tipo te encaja (y quien dice uno, dice 50), y luego te hacen el técnico como las mierdas, pues no lo vas a meter en tu equipo.
Si pasas el técnico a 100 y te lo devuelven 20 bien hecho, pues tienes a 20 candidatos para entrevistar que ya sabes que te cuadran en el perfil técnico.
No me parece ni mejor ni peor aplicar el orden que cada empresa estime, ambas tienen sus pros y contras.
#31464 La diferencia radica en invertir 20 minutos en una entrevista para hacer el corte o invertir lo que cueste contestar al email mas las dos horas del test. Ademas sin realmente haber podido preguntar nada sobre cosas especificas de la empresa en plan:
- Se usa SCRUM?
- Hay proyeccion profesional?
- Como de grande es el equipo?
- Que grado de libertad voy a tener?
- etc.
#31465 pero las 2 horas del tests no las haces tú, así que worth it.
pd: bueno, seguimos currando o qué xD
#31466 Las dos horas del candidato tienen que ser para ti de maxima importancia y eso es un detalle que muchas empresas sudan, como no es mi tiempo no importa.
Yo nunca pediria a un cadidato hacer algo que no haria yo mismo. Ademas que luego tienes que invertir tambien el tiempo en revisar el test.
Por cierto esto:
después de 10-15 minutos en la oficina, Loren y él cogen el portátil y se van a un Bar o al Starbucks y tomando un café/cerveza/refresco repasan TODO lo que el candidato quiera ver de: código fuente, configuraciones, servidores, procesos y organización del equipo de desarrollo y de Producto... y TODO lo que él quiera ver y comentar.
Me parece lo mas triste del mundo llevarte a alguien fuera de las oficinas a ense;arle todo lo que quiera ver por dos razones, un bar/cafeteria no es el sitio para ense;ar nada que requiera un minimo de concentracion y segundo, ense;ar codigo, implementacion, servidores etc a un tio que no has contratado o que no tenga firmado un NDA? Hay que ser muy patan.
#31469 evidentemente. Por eso se le da a escoger cuándo van a poder tener esas 2 horas para realizarlo, porque son de vital importancia para el proceso de selección. Claro que me importa su tiempo, en el sentido de que cuanto mejor lo hagan, mejor para ambos. Lo de que los tests se revisan, lo daba por sentado xD
