Feda /dev/ - No Javascript allowed | Página 2007

Seyriuu #60181 1 Nov

#60179 Una prueba que consuma tanto tiempo y sea tan extensa requerirá siempre un candidato dispuesto.

Filtrará automáticamente gente que pueda ser muy valida y no quiera pasar por el aro.

Como empresa quieren trabajadores que acepten lentejas y se esfuercen, pringados que sean buenos en lo técnico pero que no se hagan valer, si tienen poco orgullo y autoestima ideales.

Eso no cambia seas google o seas pyme Manolo.

Pero eso no deja de ser lo que busca la empresa, una persona por su parte puede pasar por esos aros porque le interese la empresa, lo necesite, o mil historias. No tiene porque ser un desesperado, la prueba la haran desesperados y gente que tengan interés especial, los que ni una cosa ni la otra como Kaledros lo rechazarán.

1 respuesta

Kaledros #60182 1 Nov

#60181Seyriuu:
Como empresa quieren trabajadores que acepten lentejas y se esfuercen, pringados que sean buenos en lo técnico pero que no se hagan valer, si tienen poco orgullo y autoestima ideales.

En mi experiencia, eso es atribuir a la mala leche lo que en realidad es ineptitud. Es simplemente que la gente encargada del recruitment quiere cubrirse las espaldas y es mejor poder decir "pues la prueba la pasó" que "pues a mí me pareció buen chaval".

PhDfailer #60183 1 Nov

#60179isvidal:
Pero obviamente ahi cada uno con su contexto y momento, en mi empresa se hace una vez ya has pasado el culture fit, y solo te queda la entrevista con el jefazo de web despues.

En ese caso me parece bien.

Lo que no es normal, es pringar a 8-50 personas con entrevistas técnicas que te vas a mirar en 5 minutos. Eso demuestra poco respeto al tiempo de la gente, y da una imagen malísima de la empresa.

Pero bueno es que es normal, en España el 90% de las empresas son "cárnicas" donde la calidad no importa una mierda.

JuAn4k4 #60184 1 Nov

A mi una prueba de 8h la esquivó casi siempre, en algún caso les digo mira le dedico 1-2horas y con lo que saqué opinas.

RubberDuck #60185 2 Nov

#include <desu.h>

Ya yo he aportado, que alguien haga el resto.

1 1 respuesta

ManKorR #60186 2 Nov :psyduck:

Desu vendrá mañana no?

squ4r3 #60187 2 Nov

Yo ambos trabajos que he conseguido en devops han requerido prueba técnica hecha en mi tiempo libre, pero no me importa porque como mucho ha sido un par de horas.

En uno de ellos, la prueba técnica sync era discutir lo hecho async y hablar sobre ello un par de horas. Cero problemas, prefiero eso mil veces antes que un leetcode random.

Seyriuu #60188 3 Nov

Esto de las pruebas técnicas me da una duda, ¿No es posible que la forma de trabajar de alguien en su prueba técnica sea buena y que luego los que revisen el código lo tiren para atrás porque en su opinión es mala?

O sea, que les des un código con pautas y metodologías mejor de lo que ellos mismos habrían hecho y te lo tumben porque se crean que su forma de trabajar es mejor, aunque objetivamente sea peor.

Da un poco que pensar, porque no te examinas en hacer las cosas bien, si no en acertar en hacerlas como unos desconocidos lo harían.

1 respuesta

ManKorR #60189 3 Nov :psyduck:

Se puede copiar ?

Kaledros #60190 3 Nov

#60188Seyriuu:
O sea, que les des un código con pautas y metodologías mejor de lo que ellos mismos habrían hecho y te lo tumben porque se crean que su forma de trabajar es mejor, aunque objetivamente sea peor.

En el 99% de casos, no.

Si te echan por la prueba técnica es porque no llegas al nivel que ellos quieren. Eso puede significar desde no saber hacer lo que te piden (o directamente no haberlo hecho) hasta asumir cosas que no se te piden, sobreingeniería, no haber entendido el enunciado, etc. Otra cosa es que no sepas por qué te han tumbado y pienses erróneamente que tu prueba estaba bien, pero eso es porque no te han dado feedback.

1 respuesta

Seyriuu #60191 3 Nov

#60190 No sé qué decirte, en mi trabajo hay gente que lleva 25 años haciendo los 3 mismos IF en códigos spaghettis increíbles que cuando les pides que te separen las cosas en distintos métodos para que sean códigos independientes y más fáciles de mantener en vez de ser un mismo código haciendo 12 cosas distintas y que para tocar una tengas que revisarlo entero y lo mismo rompes algo que no tiene nada que ver porque están tirando de variables globales, les vuelas la cabeza y se ofenden y se ponen a decirte que "no es necesario" y mierdas así.

Imagínate uno de esos evaluando a alguien que le da un código limpio y separado xD

2 2 respuestas

Kaledros #60192 3 Nov

#60191 Hay un montón de banderas rojas que deberían impedirte echar CV a sitios así, desde la propia oferta hasta la primera entrevista.

Vedrfolnir #60193 3 Nov

#60191 y dónde dices que curras?
Que voy a ir mirando ofertas para cambiar de curro post-navidad y por no echar ahí si la veo

1 respuesta

Seyriuu #60194 3 Nov

#60193 Consultora cárnica para un banco, aunque ya no programo, la gente a la que hacía referencia programan en un lenguaje tipo COBOL y en la vida han tenido una buena práctica ni media xD

1 2 respuestas

Vedrfolnir #60195 3 Nov

#60194 COBOL

1 respuesta

ManKorR #60196 3 Nov :psyduck:

#60194 tu que haces?

#60195 viven tranquilitos no?

1 respuesta

Seyriuu #60197 3 Nov

#60196 pregunto que tal vamos una vez a la semana o cada cinco minutos en función de si vamos bien o vamos mal

3

spidermanman #60198 3 Nov

#60185 eh escoria, si tienes los cojones de andar mandando mensaje privados tenlos para dejar abierta una posible respuesta

2

madaleno #60199 3 Nov

1

desu #60200 29d

Feliz dia del programador!

6

PiradoIV #60201 29d Brongster

En China es el 24 de Octubre. Welcome back.

afhn #60202 29d Guardia Imperial

A ver si alguien puede echarme una pequeña mano.
Estoy haciendo una migración de un servidor a spring boot 3.3.1, java 21 y tomcat 10.1. Todo va bien, he podido migrar todas las librerías y hacer funcionar el servidor. Usamos uno externo because potato, pero bueno, es lo que hay. He tenido que configurar alguna cosilla en el tomcat para el tema de certificados y toda la pesca y funcionan todas las requests por https.

El problema que tengo, que como usa el servidor ficheros .log bastante pesados, usamos log4j y está excluido el logger de spring boot. Llevo un par de días rebuscando por internet pero no encuentro nada. El tomcat no está generando ningún log, no consigo hacer que todo lo escrito en consola sea transferido a un fichero .log.

Es posible que se me esté pasando alguna configuración via properties? He probado varios sets y ninguno genera un fichero log con todo lo que sale en consola, o es posible que lo que me falte sea un appender de consola? Pero claro, si le meto el appender de consola es posible que no salga todo, si falla el inicio del tomcat antes de iniciar el servlet de spring boot, no saldrá en el log. Quizá le estoy dando demasiadas vueltas y simplemente tengo que meterle un appender de consola y fuera? Pero sinceramente me extraña que que no genere un fichero .log de forma automática el servidor, quizá se me esté pasando alguna propiedad ya no en el proyecto, si no, en el logger.properties del Tomcat, pero claro, no encuentro nada y es la primera vez que configuro un servidor de tomcat.

1 respuesta

pantocreitor #60203 29d

#60202 depende de que implementación del logger estés usando necesitas un log4j2.xml o logback.xml en la carpeta resources.
Ahí debes meter todas las configs del logger.

Edit: y depende de la config igual necesitas también algún archivo properties, pero ya mejor que te metas en la doc

1 respuesta

afhn #60204 29d Guardia Imperial

#60203 lo estoy haciendo todo programáticamente(que no me gusta, pero el TL manda), creo un ConfigurationBuilder con todos los appenders y luego lo cargo en el LoggerContext con un Initializer. Es posible que me esté cargando el logging del tomcat con esto? Porque claro, estoy reconfigurando el LoggerContext y quizás algo se pierde por medio. Que a ver, está abierta la posibilidad de hacerlo por xml si no encuentro nada, pero invertir tiempo en un tal vez que me deje en el mismo punto...

Y sería log4j2.xml pero de forma programática, el logback está excluido.

1 respuesta

pantocreitor #60205 29d

#60204 es posible que se esté cargando algo si.
Revisa bien igualmente las dependencias que si tienes librerías es posible que alguna te esté metiendo mierdas al logger.
Quita también todas las configs que tengas para comprobar que el log a pelo tira algo y ve probando.

El tema de los logs en spring es un dolor de huevos a veces xD

1 respuesta

Lecherito #60206 29d A toda leche

Hay que ser imbécil para meter spring boot en tomcat.

2 2 respuestas

afhn #60207 29d Guardia Imperial

#60205 Sí, eso hice, un dependcy:tree extenso y excluido todas las dependencias que no me cuadren, sobre todo spring boot, que te mete logback, log4j2, slf4j, etcétera.

Pues fíjate, los appenders metidos sí que loggean, lo que no se loggea es la consola, o sea un log general de todo. Probré una property de spring boot logger.file no sé qué, e incluso me generó un fichero .log, pero se queda vacío aquí falta algo o falla algo. Tal vez tenga que invertir tiempo en hacerlo vía xml y no reconfigurar el LoggerContext...

A mí el tema de logs me da tremenda pereza con spring boot, demasiada mierda, no veo que haya un standar por así decirlo, y encima viene con varios proveedores, y por último el que sea embebido el servidor o no, cambia mucho todo, pfff...

#60206 no le veo sentido tampoco. Pero estamos limitados por la sede de USA y si USA decide Tomcat... Pero bueno, supongo que también influye mucho que no seamos una factoría software o lo que sea. Me da mazo por culo muchas veces estar limitados por arriba.

1 respuesta

pantocreitor #60208 29d

#60206 undertow usamos en el curro, pero vamos, que es cambiar del malo al menos malo…

#60207 alguna config te falta casi seguro para meter los logs del level que tengas configurado en el archivo de logs.
Hace mil que no toco configs de logs porque los de devops o sistemas que llevan el pitote del loki usan un config xml que lo llevan todos los servicios
Pero me suena a eso, overwrite de la config y que falte algún parámetro o config complementaria.

Edit: ya a nivel de tomcat no se si hará falta tocar algo porque hace muuuuchos años que no toco tomcat

1 1 respuesta

Lecherito #60209 29d A toda leche

#60208 pero si la gracia de esa mierda es que ya te viene todo.

2 1 respuesta

pantocreitor #60210 29d

#60209 tomcat es el que viene por defecto en spring, pero puedes cambiarlo por alternativas “mejores”

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales