Pruebas tecnicas, desarrolladores de software

Puedes denunciar si te han echado por ser padre.

De todas formas, si, son normales las pruebas.

¿Como si no saben tu nivel?

seaman escribió:¿Como si no saben tu nivel?

¿Necesitas conocer el "nivel" de alguien con más de 10 años de experiencia, con proyectos visibles en internet y un CV cojonudo? ¿Que es el nivel? ¿con lo amplia que es la programación si alguien no escribe como a ti te gusta consideras que no tiene nivel? A mi pareja le pidieron un proyecto, tras 2 horas lo hizo, en la oferta ponía que usaban redux, sin embargo ella usó react-query porque es mejor y mas nuevo y no ponia que hubiera que usarlo en la prueba... Estaba perfecto y ni si quiera le contestaron, seguramente ni conocían react-query y ni tuvo posibilidad de defensa. Para mi las pruebas son síntoma de un trabajo de mierda.

polipeta escribió:

seaman escribió:¿Como si no saben tu nivel?

¿Necesitas conocer el "nivel" de alguien con más de 10 años de experiencia, con proyectos visibles en internet y un CV cojonudo? ¿Que es el nivel? ¿con lo amplia que es la programación si alguien no escribe como a ti te gusta consideras que no tiene nivel? A mi pareja le pidieron un proyecto, tras 2 horas lo hizo, en la oferta ponía que usaban redux, sin embargo ella usó react-query porque es mejor y mas nuevo y no ponia que hubiera que usarlo en la prueba... Estaba perfecto y ni si quiera le contestaron, seguramente ni conocían react-query y ni tuvo posibilidad de defensa. Para mi las pruebas son síntoma de un trabajo de mierda.

Ya hombre, porque esos proyectos son tuyos 100% y no has podido copiarlos. Se que no lo has hecho.
De todas formas la experiencia muchas veces no vale para nada, tengo una compañera que dice que tiene 11 años de experiencia y ha entrado a mi empresa como junior asi que a saber que habrá hecho en esos 11 años.
Yo en mi GitHub no tengo nada por ejemplo. Todo los trabajos que he hecho son de empresas privadas.

Supongo que si vas a cobrar 40k€ o 60k€ quieren ver que tengas nivel para la empresa.
Me parece normal.
Si no quieres hacer la prueba, estás en tu derecho de no hacerla. Te niegas, la empresa no te contrata y adiós.
Pero cuando llegas a un nivel es normal que la empresa quiera ver tu nivel, en mi opinión ojo.
Y soy una persona que le tocan los cojones las pruebas.

Has dicho dos cosas distintas: que no podrias hacer todas por tiempo (cuando en una indicas serían unas 4h y estás en paro) y después que por principios.

Pues mira, yo creo que es por miedo a que vean no encajas en el perfil o no saber hacer algo concreto. A mí nunca me han gustado, al igual que los test esos de lógica de mierda que sinceramente eso si que sirve de bien poco porque se entrena cual teoricos de conducción y pasa a no indicar nada de lo que pretende (o si te lo encuentras por primera vez y tiempo muy limitado que salgas pensando que eres retrasado).

Pero a lo que vamos: Si te la piden y no la haces, pues no vas a optar a ese puesto. Es bastante simple el asunto.

Entrevista técnica sí. Se puede conocer el nivel de una persona en un tema en específico preguntándole 4 tonterías. Prueba técnica, si entra dentro de un tiempo razonable (30 mins o menos), sí, durante el tiempo de la entrevista.

Prueba técnica de 4 horas porque te crees Google pero no pagas ni parecido a Google? No. Si pagases como Google me lo pensaría, pero no voy a hacer una prueba técnica en una empresa, cuando otra tiene las mismas condiciones, y no tengo que gastar medio día en una tontería que no se va a usar.

Tengo un CV que me permite tener varias ofertas sobre la mesa, no necesito gastar tiempo valioso para convencer a nadie que no me ha convencido antes a mí de que vale la pena invertir ese tiempo.

exitfor escribió:Has dicho dos cosas distintas: que no podrias hacer todas por tiempo (cuando en una indicas serían unas 4h y estás en paro) y después que por principios.

Pues mira, yo creo que es por miedo a que vean no encajas en el perfil o no saber hacer algo concreto. A mí nunca me han gustado, al igual que los test esos de lógica de mierda que sinceramente eso si que sirve de bien poco porque se entrena cual teoricos de conducción y pasa a no indicar nada de lo que pretende (o si te lo encuentras por primera vez y tiempo muy limitado que salgas pensando que eres retrasado).

Pero a lo que vamos: Si te la piden y no la haces, pues no vas a optar a ese puesto. Es bastante simple el asunto.

Ejemplo de mentalidad tóxica: Si alguien te da 2 razones, que ni siquiera son excluyentes, pero te buscas la forma de invalidar la opinión porque ha dado varias. Y así con todo en la programación ojo, cuando digo que no es por tiempo lo digo porque si los 12 procesos que tengo abiertos me las pidieran sería imposible...

Es como estos que dicen: Es que queremos que siga nuestras prácticas... Pero vamos a ver, si alguien hace un proyecto siguiendo sus propias prácticas, ¿que impide que se adapte a las de la empresa? es totalmente ridículo.

Otro ejemplo chicos: El otro día me hizo uno una prueba técnica por meets, genial. Todo respondido correctamente y se notaba que le satisfacía lo que respondía, pero resulta que me pregunta cuando usaría un "forEach"... jajaja le digo: "yo no usaria forEach, usaria siempre un for of", ni me preguntó por que ni nada (for of es más rápido que for each, la única razón de usar forEach es porque te guste más como queda escrito...) pues se le quedo cara de "ya no me gusta", para partirse de la risa, ni si quiera me envió correo de feedback. Siempre, siempre son ingenieritos

@polipeta te preguntaron cuándo usarías un for each con esos años de experiencia ?

O estabas en la criba de recien titulados o la persona que entrevistaba no es del sector y no estaba preparada para esa respuesta tuya.

exitfor escribió:@polipeta te preguntaron cuándo usarías un for each con esos años de experiencia ?

O estabas en la criba de recien titulados o la persona que entrevistaba no es del sector y no estaba preparada para esa respuesta tuya.

Te lo juro por mi vida, tío. Lo peor es que el resto de preguntas se notaba la satisfacción en la cara, pero por responder esa de una forma que no le gusta, se terminó. Es totalmente ridiculo.

Nadie te está obligando a hacer una prueba técnica...
Si no estás de acuerdo, no apliques a esa oferta y ya.

En mi caso he hecho pruebas técnicas dos veces y las dos fueron un puñetero abuso.
Una duró 3 días y pasé el corte, y al final no abrieron la empresa, porque no encontraban proyectos (Quarksoft se llamaba).

Desde luego que si tuviera que aplicar a una oferta de ese tipo y veo que me piden algo que dure más de un par de horas, ni se me pasaría por la cabeza.

En cuanto a si el ambiente es tóxico o no, pues depende.
No todos programamos igual, aunque si te piden algo concreto en un lenguaje concreto, imagino que debes usarlo.

@ajbeas
La cosa es que ninguna de las ofertas en las que he aplicado ponía lo de las pruebas, te lo sueltan al hacer la primera entrevista los muy zánganos. Me parece abusivo una prueba de 4 horas pero me apetecía saber vuestras opiniones porque considero que aceptar estas pruebas es permitir que las empresas se acostumbren y al final perjudicar al resto de desarrolladores.

La teórica se la puede saber cualquiera preparándose previamente la entrevista técnica.

Yo como Tech Lead he realizado muchas entrevistas y pruebas a la gente. Cuando hacíamos primero entrevista y luego prueba, en la entrevista parecía que sabía de todo y la prueba era un fiasco.
Cuando hicimos primero prueba y luego entrevista. Mucha gente pasaba la prueba y luego no sabía argumentar nada en la entrevista. Se notaba que había hecho la prueba o con ayuda o con trampas.

También nos llegó un tipo con 15 años de experiencia, que no había trabajado jamás en Hexagonal, ni patrones de diseño, arquitectura de software y mucho menos algoritmos. Solo había hecho plugins de Wordpress.

Evidentemente que no pasó ni la prueba ni la entrevista. Y encima iba muy de subido diciendo que el sabía de todo porque llevaba 15 años, pero teníamos Juniors con menos de 3 años de exp que le daban un repaso en arquitectura y TDD.

La prueba técnica es para filtrar. Normalmente si es una empresa de calidad, tienen prueba técnica. Lo que yo me he encontrado es que las empresas más penosas y más esclavistas, son las que no tienen prueba técnica de ningún tipo.

Pueden ser pruebas asíncronas o directamente un mob para hacer un refactor de alguna cosa en producción o hacer un TDD, pero las buenas tienen prueba técnica.

Yo, oficialmente cotizado, llevo desde los 20 y voy a cumplir 30. He cambiado de curro muchas veces y nunca he estado en más de 3 procesos a la vez, porque siempre hago criba de todas las ofertas pochas.

Las pruebas técnicas las hago todas y en muchas ocasiones te dan tiempo de sobras para hacerlas correctamente sin que haga falta hacer uso de todo el tiempo.

Una de ellas me dijeron que tenía 3 días y en 2/3 horas tenía algo medio decente y se lo entregué en un github. Mostrando todo el proceso de construcción con cada commit y aunque la prueba no era una maravilla perfecta, lo que estaba perfecto era todo el proceso de construcción, commits, refactor, test, etc.. Con solo ver eso, no les importo si finalmente funcionaba o no funcionaba (funcionaba pero no lo comprobaron, me lo dijeron ellos). Quedaron muy satisfechos y ya demostré lo que ellos querían que demostrara cuando comenté todo el proceso en la entrevista posterior.

Para eso sirve la prueba técnica. Cuando son personalizadas, aportan mucho valor y cuando son genéricas, sirven para comentarla en la entrevista posterior y argumentar.

Y, evidentemente, una muy buena prueba técnica, te da poder para negociar las condiciones. En la JD ofrecían 10K menos de lo que me dieron al final en aquella empresa. Y ni siquiera discutieron para regatearme, aceptaron pagarme directamente lo que pedía.

polipeta escribió:

exitfor escribió:@polipeta te preguntaron cuándo usarías un for each con esos años de experiencia ?

O estabas en la criba de recien titulados o la persona que entrevistaba no es del sector y no estaba preparada para esa respuesta tuya.

Te lo juro por mi vida, tío. Lo peor es que el resto de preguntas se notaba la satisfacción en la cara, pero por responder esa de una forma que no le gusta, se terminó. Es totalmente ridiculo.

A no ser que sea estrictamente necesario mejorar increiblemente la performance (cosa que en javascript, muy pocas veces se hace porque no tienes miles de objetos a recorrer), la convención es utilizar forEach para arrays asociativas y For-in en objetos. For-of no tiene callback por lo que se suele escoger forEach para simplificar el código con el callback.
Probablemente la respuesta que esperaba el pive era algo de eso, pero es muy relativo.

En muchos lenguajes ya no se prioriza la performance vs la escalabilidad. Es preferible a veces que el código sea más simple y poder sacarlo a eventos asíncronos que reducir el tiempo en 2 segundos.
Cuando simplificas las responsabilidades, es más sencillo abstraer código y reutilizarlo.

xDarkPeTruSx escribió:A no ser que sea estrictamente necesario mejorar increiblemente la performance (cosa que en javascript, muy pocas veces se hace porque no tienes miles de objetos a recorrer), la convención es utilizar forEach para arrays asociativas y For-in en objetos. For-of no tiene callback por lo que se suele escoger forEach para simplificar el código con el callback.
Probablemente la respuesta que esperaba el pive era algo de eso, pero es muy relativo.

En muchos lenguajes ya no se prioriza la performance vs la escalabilidad. Es preferible a veces que el código sea más simple y poder sacarlo a eventos asíncronos que reducir el tiempo en 2 segundos.
Cuando simplificas las responsabilidades, es más sencillo abstraer código y reutilizarlo.

Lo primero, felicidades por llegar a TL a los 30. La mayoría de los TL que veo calzan ya 40+ tacos.

Por otro lado aquí es un poco a lo que quiero llegar con que los entrevistadores se ponen un poco "pikis". Si sabes que son los callbacks, sabes que existen varias formas de plantearlo pero la práctica común en tu empresa es usar una u otra forma me parece muy rebuscado usar algo así para excluir a alguien... Como si alguien con suficiente experiencia no pudiera adaptarse a la forma de programar de la empresa. Oye, que en general, yo prefiero usar un "for of", porque muy, pero que muy pocas veces el código dentro de un bucle es reutilizable como para sacarlo a un callback aparte y a mi me parece mas legible que un forEach (de hecho también podría argumentar en esos casos te sale mejor crear una función que reciba el array y lo recorres con "for of", según el caso...). Pero ojo, que es mi gusto personal que no intento imponer a nadie y si el proyecto requiere usar forEach no se me van a caer los anillos por usarlo, sobre todo si hablamos de front.
En mi caso particular, si es mi proyecto, intento siempre tirar de perfomance, ¿porque? pues porque es mi proyecto y sé leerlo, que alguien le resulte mas o menos legible por usar un for que un forEach me parece un poco "meh". Además que siempre tengo la ilusión de que mi proyecto lo va a usar un montón de gente y prefiero la performance (me puede mi parte backend)

Yo ya hace tiempo que empecé a ver la programación como "filosofia" y todos esos argumentos no son mas que formas de imponer gustos personales, no voy a discutir con nadie por su gusto, si quieres algo de una forma en concreto me lo pides, coñe, pero asume que estás imponiendo un gusto.

Por último, lo de solo echar CV a 3 procesos, cuando todas las ofertas son super genéricas, tardan mil en completarse los procesos y no es posible ver cuales son "pochas" hasta que no pasas varias entrevistas (o incluso es imposible sin trabajar en ella) me parece poco productivo, sobre todo para alguien a quien le importa poco el tipo de proyecto o sector y prefiere estabilidad, un buen sueldo y a ser posible ya, que tengo que cuidar de una criatura.

polipeta escribió:

xDarkPeTruSx escribió:A no ser que sea estrictamente necesario mejorar increiblemente la performance (cosa que en javascript, muy pocas veces se hace porque no tienes miles de objetos a recorrer), la convención es utilizar forEach para arrays asociativas y For-in en objetos. For-of no tiene callback por lo que se suele escoger forEach para simplificar el código con el callback.
Probablemente la respuesta que esperaba el pive era algo de eso, pero es muy relativo.

En muchos lenguajes ya no se prioriza la performance vs la escalabilidad. Es preferible a veces que el código sea más simple y poder sacarlo a eventos asíncronos que reducir el tiempo en 2 segundos.
Cuando simplificas las responsabilidades, es más sencillo abstraer código y reutilizarlo.

Lo primero, felicidades por llegar a TL a los 30. La mayoría de los TL que veo calzan ya 40+ tacos.

Por otro lado aquí es un poco a lo que quiero llegar con que los entrevistadores se ponen un poco "pikis". Si sabes que son los callbacks, sabes que existen varias formas de plantearlo pero la práctica común en tu empresa es usar una u otra forma me parece muy rebuscado usar algo así para excluir a alguien... Como si alguien con suficiente experiencia no pudiera adaptarse a la forma de programar de la empresa. Oye, que en general, yo prefiero usar un "for of", porque muy, pero que muy pocas veces el código dentro de un bucle es reutilizable como para sacarlo a un callback aparte y a mi me parece mas legible que un forEach (de hecho también podría argumentar en esos casos te sale mejor crear una función que reciba el array y lo recorres con "for of", según el caso...). Pero ojo, que es mi gusto personal que no intento imponer a nadie y si el proyecto requiere usar forEach no se me van a caer los anillos por usarlo, sobre todo si hablamos de front.
En mi caso particular, si es mi proyecto, intento siempre tirar de perfomance, ¿porque? pues porque es mi proyecto y sé leerlo, que alguien le resulte mas o menos legible por usar un for que un forEach me parece un poco "meh". Además que siempre tengo la ilusión de que mi proyecto lo va a usar un montón de gente y prefiero la performance (me puede mi parte backend)

Yo ya hace tiempo que empecé a ver la programación como "filosofia" y todos esos argumentos no son mas que formas de imponer gustos personales, no voy a discutir con nadie por su gusto, si quieres algo de una forma en concreto me lo pides, coñe, pero asume que estás imponiendo un gusto.

Por último, lo de solo echar CV a 3 procesos, cuando todas las ofertas son super genéricas, tardan mil en completarse los procesos y no es posible ver cuales son "pochas" hasta que no pasas varias entrevistas (o incluso es imposible sin trabajar en ella) me parece poco productivo, sobre todo para alguien a quien le importa poco el tipo de proyecto o sector y prefiere estabilidad, un buen sueldo y a ser posible ya, que tengo que cuidar de una criatura.

Bueno, me tiré hace dos findes haciendo un proyecto en DDD super currado porque es lo que he estado haciendo el último año en Symfony porque es lo que utilizan en la empresa de la oferta.
Y ellos no usan DDD y no les gustó que lo hiciera así y parece que tampoco les gustaron mis respuestas porque me dijeron que no había pasado la entrevista técnica o que no les había gustado mi forma de hacer las cosas, no lo escuché bien.
Pues que les den.
La verdad es que me lo pasé pipa haciendo el proyecto y ya lo tengo para futuras pruebas técnicas de base por si lo necesitara.

@seaman

Pues es que para eso hago yo mis propios proyectos. Tengo una miniempresa (no facturamos nah) con la que algún día espero poder apañarmelas sin depender de nadie, en esta empresa tengo un par de proyectos super top... Nada de calculadores ni mierdas, proyectos serios que se pueden visitar (un SaaS y una plataforma completa que tiene portal web y aplicación para iOS y Android). Si alguien quiere ver mis skills que me pida mostrarle mi github en una entrevista por videollamada, pero ni de coña les doy acceso y mucho menos quiero perder horas de mi vida en chorraditas cuando ya hago yo mis cositas y mucho mejores que cualquier prueba técnica que me puedan pedir.

polipeta escribió:@seaman

Pues es que para eso hago yo mis propios proyectos. Tengo una miniempresa (no facturamos nah) con la que algún día espero poder apañarmelas sin depender de nadie, en esta empresa tengo un par de proyectos super top... Nada de calculadores ni mierdas, proyectos serios que se pueden visitar (un SaaS y una plataforma completa que tiene portal web y aplicación para iOS y Android). Si alguien quiere ver mis skills que me pida mostrarle mi github en una entrevista por videollamada, pero ni de coña les doy acceso y mucho menos quiero perder horas de mi vida en chorraditas cuando ya hago yo mis cositas y mucho mejores que cualquier prueba técnica que me puedan pedir.

Pues ya está, cuando te manden una prueba les dices que pasas y ya está.
Estás en todo tu derecho y te apoyo.
Pero entiendo a las empresas que lo hacen, los años de experiencia no valen para nada.

Este hilo me ha venido de anillo al dedo. Con respeto y permiso del creador del hilo os comento mi situación por si podéis guiarme.

Este mes he acabado el grado superior de DAM, en la empresa que estoy de prácticas me han comentado que la única manera de quedarme es con otro contrato de prácticas extra curriculares a 300€ al mes hasta septiembre…

Estoy bastante agobiado ya que obviamente esta oferta no la puedo coger, llevo ya 3 meses sin cobrar desde que dejé el trabajo y no puedo estar otros tres ganando solo eso, ahora el problema es que recién acabado el grado superior cual es la mejor manera de preparar las pruebas técnicas.
Supongo que me las pedirán y aún habiendo sacado notas muy altas me siento algo verde para estas mismas…

Cualquier ayuda os la agradezco muchísimo.

@DokkanVGC El problema es pensar que te van a pedir pruebas técnicas ahora mismo si o si. A mi nunca me las han pedido con mas o menos 8 años de exp, aunque tampoco es que haya hecho muchas entrevistas (unas 5 en total, he tenido suerte con los trabajos). Solo entrevistas técnicas, algún examen de código, algoritmos, esos exámenes chorras de lógica...

Según dicen más arriba, cuanta más exp tengas y mas arriba apuntes, mas probabilidades hay que te pidan una prueba técnica. Y si acabas de salir de estudiar es poco probable.

Cranex escribió:@DokkanVGC El problema es pensar que te van a pedir pruebas técnicas ahora mismo si o si. A mi :nunca me las han pedido con mas o menos 8 años de exp, aunque tampoco es que haya hecho muchas entrevistas (unas 5 en total, he tenido suerte con los trabajos). Solo entrevistas técnicas, algún examen de código, algoritmos, esos exámenes chorras de lógica...

Según dicen más arriba, cuanta más exp tengas y mas arriba apuntes, mas probabilidades hay que te pidan una prueba técnica. Y si acabas de salir de estudiar es poco probable.

Me ha tranquilizado bastante tu comentario, yo pienso como tú para cobrar 17-19k que cobraré supongo como Junior no creo que haya tanto jaleo pero el tutor me dijo lo contrario y bueno aquí estoy agobiado ya que la oferta de la empresa de prácticas me parece escasa.

DokkanVGC escribió:

Cranex escribió:@DokkanVGC El problema es pensar que te van a pedir pruebas técnicas ahora mismo si o si. A mi :nunca me las han pedido con mas o menos 8 años de exp, aunque tampoco es que haya hecho muchas entrevistas (unas 5 en total, he tenido suerte con los trabajos). Solo entrevistas técnicas, algún examen de código, algoritmos, esos exámenes chorras de lógica...

Según dicen más arriba, cuanta más exp tengas y mas arriba apuntes, mas probabilidades hay que te pidan una prueba técnica. Y si acabas de salir de estudiar es poco probable.

Me ha tranquilizado bastante tu comentario, yo pienso como tú para cobrar 17-19k que cobraré supongo como Junior no creo que haya tanto jaleo pero el tutor me dijo lo contrario y bueno aquí estoy agobiado ya que la oferta de la empresa de prácticas me parece escasa.

Tírale a saco, no te preocupes que hay bastante curro y ahora dan mas oportunidades a los junior que en mis tiempos, veo bastantes ofertas buscando juniors y cuando yo empecé no había ni una, me tuve que montar un proyecto web que usaban un montón de bloguers y tener la suerte de que una startup la viera, ahora miras en infojobs y ponen claramente que buscan juniors sin experiencia, eso mola así que sin miedo.

polipeta escribió:Lo primero, felicidades por llegar a TL a los 30. La mayoría de los TL que veo calzan ya 40+ tacos.

Por otro lado aquí es un poco a lo que quiero llegar con que los entrevistadores se ponen un poco "pikis". Si sabes que son los callbacks, sabes que existen varias formas de plantearlo pero la práctica común en tu empresa es usar una u otra forma me parece muy rebuscado usar algo así para excluir a alguien... Como si alguien con suficiente experiencia no pudiera adaptarse a la forma de programar de la empresa. Oye, que en general, yo prefiero usar un "for of", porque muy, pero que muy pocas veces el código dentro de un bucle es reutilizable como para sacarlo a un callback aparte y a mi me parece mas legible que un forEach (de hecho también podría argumentar en esos casos te sale mejor crear una función que reciba el array y lo recorres con "for of", según el caso...). Pero ojo, que es mi gusto personal que no intento imponer a nadie y si el proyecto requiere usar forEach no se me van a caer los anillos por usarlo, sobre todo si hablamos de front.
En mi caso particular, si es mi proyecto, intento siempre tirar de perfomance, ¿porque? pues porque es mi proyecto y sé leerlo, que alguien le resulte mas o menos legible por usar un for que un forEach me parece un poco "meh". Además que siempre tengo la ilusión de que mi proyecto lo va a usar un montón de gente y prefiero la performance (me puede mi parte backend)

Yo ya hace tiempo que empecé a ver la programación como "filosofia" y todos esos argumentos no son mas que formas de imponer gustos personales, no voy a discutir con nadie por su gusto, si quieres algo de una forma en concreto me lo pides, coñe, pero asume que estás imponiendo un gusto.

Por último, lo de solo echar CV a 3 procesos, cuando todas las ofertas son super genéricas, tardan mil en completarse los procesos y no es posible ver cuales son "pochas" hasta que no pasas varias entrevistas (o incluso es imposible sin trabajar en ella) me parece poco productivo, sobre todo para alguien a quien le importa poco el tipo de proyecto o sector y prefiere estabilidad, un buen sueldo y a ser posible ya, que tengo que cuidar de una criatura.

Lo primero, gracias por la parte que me toca

Y a continuación:

Si, los entrevistadores se ponen "pikis" y exquisitos porque muchas veces no tienen ni idea. Algunos tech leads o team leads si hacen procesos de selección, pueden verse amenazados si ven a alguien muy bueno y de la misma manera tampoco saben ver si hay potencial en alguien. Mucha gente llega a Team Lead o Tech lead (incluso a CTO) simplemente porque son muy buenos programando, pero un buen programador no tiene porque ser buen líder. Son skills muy diferentes y no están relacionadas. Saber 10 lenguajes de programación no ayuda a tener esa visión de determinar el potencial de una persona o saber si se adaptará bien a los cambios o la forma de trabajar de las empresas. Por eso muchos buscan gente que hayan trabajado de la misma manera.

Hay varias escuelas que se han asentado y las formas de trabajar de muchas empresas son así porque uno se levantó un dia y dijo "lo hacemos así". Te puedes encontrar los más puristas que siguen a raja tabla SOLID o las prácticas DDD de Carlos Buenosvinos. Hay otros que están obsesionados con Robert C Martin.

Pero al final la comunidad de cada lenguaje llega a ciertos acuerdos (en unos lenguajes más que en otros) y acaba siendo como la fuente de la verdad, cuando no tiene por qué.

Lo que más o menos he visto que está más extendido es SOLID, tanto el principio de responsabilidad única como el de Liskov.


Lo de solo entrar en 3 o 4 procesos, viene a que normalmente no busco por LinkedIn, si no en otras fuentes donde la información de la JD es mucho más explicita.

Y los trabajos que son en inglés suelen dar mejor la información, o por lo menos yo me he encontrado eso. Que entre toda la purria, en realidad solo 3 o 4 ofertas merecían realmente la pena. En muchas ofertas, por las frases o la forma de comunicar, ya sabes que la cosa no pinta bien. Y si encima te esconden el rango salarial y no te lo quieren decir en la primera entrevista... NEXT.

DokkanVGC escribió:

Cranex escribió:@DokkanVGC El problema es pensar que te van a pedir pruebas técnicas ahora mismo si o si. A mi :nunca me las han pedido con mas o menos 8 años de exp, aunque tampoco es que haya hecho muchas entrevistas (unas 5 en total, he tenido suerte con los trabajos). Solo entrevistas técnicas, algún examen de código, algoritmos, esos exámenes chorras de lógica...

Según dicen más arriba, cuanta más exp tengas y mas arriba apuntes, mas probabilidades hay que te pidan una prueba técnica. Y si acabas de salir de estudiar es poco probable.

Me ha tranquilizado bastante tu comentario, yo pienso como tú para cobrar 17-19k que cobraré supongo como Junior no creo que haya tanto jaleo pero el tutor me dijo lo contrario y bueno aquí estoy agobiado ya que la oferta de la empresa de prácticas me parece escasa.

Estudia inglés desde ya. Si necesitas curro para pagar las clases y eso, pilla lo primero que veas, aunque sea una cárnica, porque aprenderás bastante aunque estés puteado, pero estarás puteado lo mínimo indispensable para tener un nivel de inglés aceptable como para saltar a ofertas de 40K en Europa y a partir de ahí, a aprender y crecer.

Y por mucho que digan, hay muchísima oferta en remoto, pero si te gusta ir a una oficina y separar tu casa del curro, un coworking. Conoces gente, te relacionas y puedes elegir el que te salga de las narices.

Para preparar pruebas técnicas....

https://kata-log.rocks/tdd

En muchas empresas te pedirán TDD. Katas a punta pala. Tienes millones de líneas de código en github, katas para hacer, katas resueltas... No elijas el lenguaje de programación de moda. Elige el que más te guste y tira para adelante. Como escojas algo que no te guste solo porque tiene más demanda, vas a acabar hasta las narices.

Si, puede haber más demanda de X o Y lenguaje, pero no es como lo pintan ni por asomo. Si buscas, tienes ofertas. Si no encuentras es porque no estás buscando en el sitio adecuado. Y buscando bien, hay ofertas que te turbo-cagas encima de lo guapas que son.

No entiendo las reticencias a las pruebas tecnicas, si eres tan bueno deberian valerte para hacerte con los mejores puestos. Los que les tendrian que tener miedo son los malos.

Por principios no se deben hacer pruebas técnicas.

Los que hacen pruebas técnicas son directamente personas que no saben valorar a las personas como lo que son y lo que buscan son máquinas que reproducen código como ellos (o su empresa). Básicamente son buscadores de pica código.

Hay mucho entrevistador que se ha leído cuatro artículos, se sabe dos patrones y cuatro palabras en inglés y lo que quiere es que tú pienses como el.

Por principios, no a las pruebas técnicas.

Los mejores equipos de trabajo son aquellos que miran por las personas y saben valorarlas. Muchas veces una persona a priori peor técnicamente es mucho mejor integrante del equipo porque quizá lo que quiere es aprender y aportar otro valor. Hay muchas personas técnicamente buenas y que luego no saben integrarse en un equipo.

El carnet de conducir es una prueba técnica que todo el mundo pasa, pero luego ya vemos como se conduce en la calle.

xDarkPeTruSx escribió:

polipeta escribió:Lo primero, felicidades por llegar a TL a los 30. La mayoría de los TL que veo calzan ya 40+ tacos.

Por otro lado aquí es un poco a lo que quiero llegar con que los entrevistadores se ponen un poco "pikis". Si sabes que son los callbacks, sabes que existen varias formas de plantearlo pero la práctica común en tu empresa es usar una u otra forma me parece muy rebuscado usar algo así para excluir a alguien... Como si alguien con suficiente experiencia no pudiera adaptarse a la forma de programar de la empresa. Oye, que en general, yo prefiero usar un "for of", porque muy, pero que muy pocas veces el código dentro de un bucle es reutilizable como para sacarlo a un callback aparte y a mi me parece mas legible que un forEach (de hecho también podría argumentar en esos casos te sale mejor crear una función que reciba el array y lo recorres con "for of", según el caso...). Pero ojo, que es mi gusto personal que no intento imponer a nadie y si el proyecto requiere usar forEach no se me van a caer los anillos por usarlo, sobre todo si hablamos de front.
En mi caso particular, si es mi proyecto, intento siempre tirar de perfomance, ¿porque? pues porque es mi proyecto y sé leerlo, que alguien le resulte mas o menos legible por usar un for que un forEach me parece un poco "meh". Además que siempre tengo la ilusión de que mi proyecto lo va a usar un montón de gente y prefiero la performance (me puede mi parte backend)

Yo ya hace tiempo que empecé a ver la programación como "filosofia" y todos esos argumentos no son mas que formas de imponer gustos personales, no voy a discutir con nadie por su gusto, si quieres algo de una forma en concreto me lo pides, coñe, pero asume que estás imponiendo un gusto.

Por último, lo de solo echar CV a 3 procesos, cuando todas las ofertas son super genéricas, tardan mil en completarse los procesos y no es posible ver cuales son "pochas" hasta que no pasas varias entrevistas (o incluso es imposible sin trabajar en ella) me parece poco productivo, sobre todo para alguien a quien le importa poco el tipo de proyecto o sector y prefiere estabilidad, un buen sueldo y a ser posible ya, que tengo que cuidar de una criatura.

Lo primero, gracias por la parte que me toca

Y a continuación:

Si, los entrevistadores se ponen "pikis" y exquisitos porque muchas veces no tienen ni idea. Algunos tech leads o team leads si hacen procesos de selección, pueden verse amenazados si ven a alguien muy bueno y de la misma manera tampoco saben ver si hay potencial en alguien. Mucha gente llega a Team Lead o Tech lead (incluso a CTO) simplemente porque son muy buenos programando, pero un buen programador no tiene porque ser buen líder. Son skills muy diferentes y no están relacionadas. Saber 10 lenguajes de programación no ayuda a tener esa visión de determinar el potencial de una persona o saber si se adaptará bien a los cambios o la forma de trabajar de las empresas. Por eso muchos buscan gente que hayan trabajado de la misma manera.

Hay varias escuelas que se han asentado y las formas de trabajar de muchas empresas son así porque uno se levantó un dia y dijo "lo hacemos así". Te puedes encontrar los más puristas que siguen a raja tabla SOLID o las prácticas DDD de Carlos Buenosvinos. Hay otros que están obsesionados con Robert C Martin.

Pero al final la comunidad de cada lenguaje llega a ciertos acuerdos (en unos lenguajes más que en otros) y acaba siendo como la fuente de la verdad, cuando no tiene por qué.

Lo que más o menos he visto que está más extendido es SOLID, tanto el principio de responsabilidad única como el de Liskov.


Lo de solo entrar en 3 o 4 procesos, viene a que normalmente no busco por LinkedIn, si no en otras fuentes donde la información de la JD es mucho más explicita.

Y los trabajos que son en inglés suelen dar mejor la información, o por lo menos yo me he encontrado eso. Que entre toda la purria, en realidad solo 3 o 4 ofertas merecían realmente la pena. En muchas ofertas, por las frases o la forma de comunicar, ya sabes que la cosa no pinta bien. Y si encima te esconden el rango salarial y no te lo quieren decir en la primera entrevista... NEXT.

DokkanVGC escribió:

Cranex escribió:@DokkanVGC El problema es pensar que te van a pedir pruebas técnicas ahora mismo si o si. A mi :nunca me las han pedido con mas o menos 8 años de exp, aunque tampoco es que haya hecho muchas entrevistas (unas 5 en total, he tenido suerte con los trabajos). Solo entrevistas técnicas, algún examen de código, algoritmos, esos exámenes chorras de lógica...

Según dicen más arriba, cuanta más exp tengas y mas arriba apuntes, mas probabilidades hay que te pidan una prueba técnica. Y si acabas de salir de estudiar es poco probable.

Me ha tranquilizado bastante tu comentario, yo pienso como tú para cobrar 17-19k que cobraré supongo como Junior no creo que haya tanto jaleo pero el tutor me dijo lo contrario y bueno aquí estoy agobiado ya que la oferta de la empresa de prácticas me parece escasa.

Estudia inglés desde ya. Si necesitas curro para pagar las clases y eso, pilla lo primero que veas, aunque sea una cárnica, porque aprenderás bastante aunque estés puteado, pero estarás puteado lo mínimo indispensable para tener un nivel de inglés aceptable como para saltar a ofertas de 40K en Europa y a partir de ahí, a aprender y crecer.

Y por mucho que digan, hay muchísima oferta en remoto, pero si te gusta ir a una oficina y separar tu casa del curro, un coworking. Conoces gente, te relacionas y puedes elegir el que te salga de las narices.

Para preparar pruebas técnicas....

https://kata-log.rocks/tdd

En muchas empresas te pedirán TDD. Katas a punta pala. Tienes millones de líneas de código en github, katas para hacer, katas resueltas... No elijas el lenguaje de programación de moda. Elige el que más te guste y tira para adelante. Como escojas algo que no te guste solo porque tiene más demanda, vas a acabar hasta las narices.

Si, puede haber más demanda de X o Y lenguaje, pero no es como lo pintan ni por asomo. Si buscas, tienes ofertas. Si no encuentras es porque no estás buscando en el sitio adecuado. Y buscando bien, hay ofertas que te turbo-cagas encima de lo guapas que son.

Coño, te dejas el clean architecture.
No es necesario tener DDD para tener un buen código pero si que siga los principios clean y SOLID.
Te dejas el principio open close o el dependency inversion principle. Depender de interfaces en vez de clases concretas te da mucha más versatilidad en tu código.

La religion de los patrones y la sobre ingeniería en su pleno apogeo.

Cada problema tiene una solución y no todos los problemas se resuelven con la misma solución por mucho que uno crea en 'su propia' solución.

seaman escribió:Coño, te dejas el clean architecture.
No es necesario tener DDD para tener un buen código pero si que siga los principios clean y SOLID.
Te dejas el principio open close o el dependency inversion principle. Depender de interfaces en vez de clases concretas te da mucha más versatilidad en tu código.

No no, sin duda, pero en las empresas que he estado, normalmente se ponen más pikis con SRP y Liskov.

Y lo del DDD es porque se ha puesto más de moda y ya llevo varios años con DDD y CQRS.

Ahora usamos mucho el XP y para todas las tareas siempre empezamos con refactor preparatorio, dejando el código mejor antes de empezar con las features. No es que tengamos un Legacy infinito, porque realmente de Legacy hay poco, pero lo que se hizo hace 2 años tiene una estructura diferente al estilo que utilizamos desde que yo entré y claro... aun hace falta meterle mano a algunas cosas.

xDarkPeTruSx escribió:

polipeta escribió:Lo primero, felicidades por llegar a TL a los 30. La mayoría de los TL que veo calzan ya 40+ tacos.

Por otro lado aquí es un poco a lo que quiero llegar con que los entrevistadores se ponen un poco "pikis". Si sabes que son los callbacks, sabes que existen varias formas de plantearlo pero la práctica común en tu empresa es usar una u otra forma me parece muy rebuscado usar algo así para excluir a alguien... Como si alguien con suficiente experiencia no pudiera adaptarse a la forma de programar de la empresa. Oye, que en general, yo prefiero usar un "for of", porque muy, pero que muy pocas veces el código dentro de un bucle es reutilizable como para sacarlo a un callback aparte y a mi me parece mas legible que un forEach (de hecho también podría argumentar en esos casos te sale mejor crear una función que reciba el array y lo recorres con "for of", según el caso...). Pero ojo, que es mi gusto personal que no intento imponer a nadie y si el proyecto requiere usar forEach no se me van a caer los anillos por usarlo, sobre todo si hablamos de front.
En mi caso particular, si es mi proyecto, intento siempre tirar de perfomance, ¿porque? pues porque es mi proyecto y sé leerlo, que alguien le resulte mas o menos legible por usar un for que un forEach me parece un poco "meh". Además que siempre tengo la ilusión de que mi proyecto lo va a usar un montón de gente y prefiero la performance (me puede mi parte backend)

Yo ya hace tiempo que empecé a ver la programación como "filosofia" y todos esos argumentos no son mas que formas de imponer gustos personales, no voy a discutir con nadie por su gusto, si quieres algo de una forma en concreto me lo pides, coñe, pero asume que estás imponiendo un gusto.

Por último, lo de solo echar CV a 3 procesos, cuando todas las ofertas son super genéricas, tardan mil en completarse los procesos y no es posible ver cuales son "pochas" hasta que no pasas varias entrevistas (o incluso es imposible sin trabajar en ella) me parece poco productivo, sobre todo para alguien a quien le importa poco el tipo de proyecto o sector y prefiere estabilidad, un buen sueldo y a ser posible ya, que tengo que cuidar de una criatura.

Lo primero, gracias por la parte que me toca

Y a continuación:

Si, los entrevistadores se ponen "pikis" y exquisitos porque muchas veces no tienen ni idea. Algunos tech leads o team leads si hacen procesos de selección, pueden verse amenazados si ven a alguien muy bueno y de la misma manera tampoco saben ver si hay potencial en alguien. Mucha gente llega a Team Lead o Tech lead (incluso a CTO) simplemente porque son muy buenos programando, pero un buen programador no tiene porque ser buen líder. Son skills muy diferentes y no están relacionadas. Saber 10 lenguajes de programación no ayuda a tener esa visión de determinar el potencial de una persona o saber si se adaptará bien a los cambios o la forma de trabajar de las empresas. Por eso muchos buscan gente que hayan trabajado de la misma manera.

Hay varias escuelas que se han asentado y las formas de trabajar de muchas empresas son así porque uno se levantó un dia y dijo "lo hacemos así". Te puedes encontrar los más puristas que siguen a raja tabla SOLID o las prácticas DDD de Carlos Buenosvinos. Hay otros que están obsesionados con Robert C Martin.

Pero al final la comunidad de cada lenguaje llega a ciertos acuerdos (en unos lenguajes más que en otros) y acaba siendo como la fuente de la verdad, cuando no tiene por qué.

Lo que más o menos he visto que está más extendido es SOLID, tanto el principio de responsabilidad única como el de Liskov.


Lo de solo entrar en 3 o 4 procesos, viene a que normalmente no busco por LinkedIn, si no en otras fuentes donde la información de la JD es mucho más explicita.

Y los trabajos que son en inglés suelen dar mejor la información, o por lo menos yo me he encontrado eso. Que entre toda la purria, en realidad solo 3 o 4 ofertas merecían realmente la pena. En muchas ofertas, por las frases o la forma de comunicar, ya sabes que la cosa no pinta bien. Y si encima te esconden el rango salarial y no te lo quieren decir en la primera entrevista... NEXT.

DokkanVGC escribió:

Cranex escribió:@DokkanVGC El problema es pensar que te van a pedir pruebas técnicas ahora mismo si o si. A mi :nunca me las han pedido con mas o menos 8 años de exp, aunque tampoco es que haya hecho muchas entrevistas (unas 5 en total, he tenido suerte con los trabajos). Solo entrevistas técnicas, algún examen de código, algoritmos, esos exámenes chorras de lógica...

Según dicen más arriba, cuanta más exp tengas y mas arriba apuntes, mas probabilidades hay que te pidan una prueba técnica. Y si acabas de salir de estudiar es poco probable.

Me ha tranquilizado bastante tu comentario, yo pienso como tú para cobrar 17-19k que cobraré supongo como Junior no creo que haya tanto jaleo pero el tutor me dijo lo contrario y bueno aquí estoy agobiado ya que la oferta de la empresa de prácticas me parece escasa.

Estudia inglés desde ya. Si necesitas curro para pagar las clases y eso, pilla lo primero que veas, aunque sea una cárnica, porque aprenderás bastante aunque estés puteado, pero estarás puteado lo mínimo indispensable para tener un nivel de inglés aceptable como para saltar a ofertas de 40K en Europa y a partir de ahí, a aprender y crecer.

Y por mucho que digan, hay muchísima oferta en remoto, pero si te gusta ir a una oficina y separar tu casa del curro, un coworking. Conoces gente, te relacionas y puedes elegir el que te salga de las narices.

Para preparar pruebas técnicas....

https://kata-log.rocks/tdd

En muchas empresas te pedirán TDD. Katas a punta pala. Tienes millones de líneas de código en github, katas para hacer, katas resueltas... No elijas el lenguaje de programación de moda. Elige el que más te guste y tira para adelante. Como escojas algo que no te guste solo porque tiene más demanda, vas a acabar hasta las narices.

Si, puede haber más demanda de X o Y lenguaje, pero no es como lo pintan ni por asomo. Si buscas, tienes ofertas. Si no encuentras es porque no estás buscando en el sitio adecuado. Y buscando bien, hay ofertas que te turbo-cagas encima de lo guapas que son.

Primero de todo agradecerte como siempre tus post tan detallados que como de costumbre son de gran ayuda.

Ahora, sobre el inglés no tengo problema soy bilingüe y este verano me sacaré la titulación oficial C1, también tengo buenas nociones con titulación en alemán (B1) y francés (B1). He estado todo el día estructurando el CV para que se vea lo más profesional posible y a ver si así hay suerte y alguna empresa me contrata como Junior.
En la hoja de ruta que me he creado he incluido dedicarle todos los días al menos una hora y media a preparar las pruebas técnicas con la página que me has proporcionado.

De nuevo muchas gracias y si tenéis cualquier consejo que darme os lo agradezco mucho.

@xDarkPeTruSx

Pues me encantaría saber donde buscas curro, uso linkedin e infojobs y la verdad es que muy pocas traen el rango salarial. También es cierto que soy yo el que pone el rango en el que me encuentro + un % extra para aumentar cada año (ahora estoy en 42/45K). También es cierto que tiendo a ser positivo y me cuesta fijarme en las red flags, siempre pienso que mientras me dejen hacer mi trabajo, haya teletrabajo y no me toque un nazi tocapelotas obsesionado con las palabritas que ha leído en cualquier sitio, ya es un buen sitio.

Dartanyan escribió:La religion de los patrones y la sobre ingeniería en su pleno apogeo.

Cada problema tiene una solución y no todos los problemas se resuelven con la misma solución por mucho que uno crea en 'su propia' solución.

He aquí el tema, no estoy nada a favor de estos cantamañanas que quieren imponer una única perspectiva, en general, por lo que he visto, son gente demasiado criticona y que considera que su forma es la única forma correcta de plantear las cosas. Para mi es una de las grandes red flags y prefiero no entrar en un sitio con gente así, convierten el día a día en una batalla y joder... Que no van a cobrar mas por ralentizar el trabajo del resto, si el único problema que tiene el código es que no está a tu gusto déjalo, coñe, si funciona no lo toques. A mi me resulta facilisimo leer el código de otros aunque no siga mi forma de actuar, pero si tiene lógica y no hay bugs palante hostia.

@DokkanVGC

Mi único consejo es que disfrutes la programación y procures llevarte bien con tus compañeros, eso implica que si no eres TL o responsable no des por culo a tus compañeros y no entres en discusiones sobre como hacer X... Que sea siempre el responsable/TL el que tenga la última palabra, verás como estos, cuando vean que no pueden avanzar con su trabajo porque les preguntan por todo, empiezan a volverse mas laxos y no tan tocapelotas.

@polipeta

Hay muchos sitios para buscar. Yo para la última, utilicé esta web:

https://hiring.cafe/

Tenía varios marcadores de sitios, pero no sé que ha pasado que ya no los encuentro.

Lo principal es buscar "europe" "software engineer", "remote" y tal. Si lo buscas en ingés en el propio google, encuentras webs con bastantes ofertas.

En Infojobs encontré mi primer curro cuando aún estudiaba y no he vuelto a encontrar nada potable.

En LinkedIn a veces se encuentran ofertas interesantes, pero startups que a veces tienen condiciones interesantes pero también promesas que puede que no se cumplan (stocks si la empresa crece, revisión salarial si todo va bien económicamente....)

Aunque yo mismo he pasado por el aro de hacer pruebas técnicas y gracias a la última acabé en la empresa en la que estoy actualmente, me parecen un mal innecesario y que deberíamos erradicar.

No solo el empleado puede mentir durante la entrevista, también el empleador acerca de las condiciones, el ambiente de trabajo o, incluso, las propias metodologías y recursos o tecnologías con los que se trabaja. Que yo sepa, desde nuestro lado no tenemos forma de comprobar de antemano y sin percibir salario si la oferta nos convence o se adapta a lo que buscamos; o si es cierto lo que prometen. Para eso está el periodo de prueba, que no obliga a ningún tipo de preaviso ni indemnización (y el finiquito es irrisorio).

Y si hacen prueba técnica y se supera satisfactoriamente, que no incluyan un periodo de prueba.

@DokkanVGC Pues partir siendo bilingüe ya es una ventaja enorme. Yo apenas me voy a apuntar a la EOI para ver si me saco algún certificado (he estado haciendo exámenes de años anteriores y los B1 estan tirados)

@xDarkPeTruSx Antes has dicho del nivel aceptable de ingles para saltar a Europa. ¿Que nivel sería ese?¿Imagino que el C1 no?

Alonso707 escribió:Aunque yo mismo he pasado por el aro de hacer pruebas técnicas y gracias a la última acabé en la empresa en la que estoy actualmente, me parecen un mal innecesario y que deberíamos erradicar.

No solo el empleado puede mentir durante la entrevista, también el empleador acerca de las condiciones, el ambiente de trabajo o, incluso, las propias metodologías y recursos o tecnologías con los que se trabaja. Que yo sepa, desde nuestro lado no tenemos forma de comprobar de antemano y sin percibir salario si la oferta nos convence o se adapta a lo que buscamos; o si es cierto lo que prometen. Para eso está el periodo de prueba, que no obliga a ningún tipo de preaviso ni indemnización (y el finiquito es irrisorio).

Y si hacen prueba técnica y se supera satisfactoriamente, que no incluyan un periodo de prueba.

Exacto, tu tienes que confiar en lo que te cuenta la empresa pero la empresa no puede confiar en lo que tu le cuentas.

Y ademas luego hay empleados encantados de la vida yendo de 'cualificadores' capaces de distinguir entre lo que es tener conocimientos técnicos o no. Gente que vive en su mundo y de ahi no los saques.

Si es que tenemos lo que nos merecemos.

Ya me he cruzado con muchos de estos que hablan solo con acrónimos y luego el trabajo que van dejando se puede calificar únicamente de porqueria.

Cranex escribió:@DokkanVGC Pues partir siendo bilingüe ya es una ventaja enorme. Yo apenas me voy a apuntar a la EOI para ver si me saco algún certificado (he estado haciendo exámenes de años anteriores y los B1 estan tirados)

@xDarkPeTruSx Antes has dicho del nivel aceptable de ingles para saltar a Europa. ¿Que nivel sería ese?¿Imagino que el C1 no?

Entre B2 y C1.

Poder mantener una conversación sobre cualquier tema.
Explicar situaciones cotidianas de la vida y del trabajo.
Entender correctamente lo que te dicen aunque hablen a una velocidad considerable.

Normalmente si te puedes expresar correctamente y seguir el hilo de una conversación, no necesitas sacarte titulaciones. Yo no las tengo y trabajo en inglés.

Básicamente es defenderte y entenderlo aunque te falte algo de vocabulario y soltura, pero eso, currando cada dia, se pilla rapidisimo, en 2 semanas estas hablando inglés por los codos.

Por suerte nunca las tuve que hacer, siempre me pareció una gilipollez y ya si te empiezan a preguntar chorradas de lenguajes que en 1 minuto te ha resuelto google. A mi se me da fatal explicar toda esa jerga tecnica pero luego soy muy resolutivo y te lo hago eficientemente en nada, por suerte ya no tengo que pasar por eso nunca mas.

Ahora bien, si quieres acceder a un buen puesto te va a tocar pasar por el aro, la putada es cuando se aprovechan y solo querian que se lo hicieras para sacarles trabajo y no te cogen.

Os pregunto una cosa, a un obrero le dicen que haga una casa antes para ver si lo pueden contratar? Pues eso.

Dartanyan escribió:La religion de los patrones y la sobre ingeniería en su pleno apogeo.

Cada problema tiene una solución y no todos los problemas se resuelven con la misma solución por mucho que uno crea en 'su propia' solución.

Es que los patrones de diseño son eso, soluciones que mucha gente ha usado para un mismo problema y una persona hizo una recopilación de los más útiles/famosos.
No son una regla ni una solución concreta, son un diseño y podrás adaptarlo más o menos a tu propia solución.
Seguramente muchos hayamos usado patrones de diseño sin saberlo.

Y el DDD es otra forma de crear una aplicación siguiendo una serie de reglas. Ya está.
Lo mejor del DDD es que es muy testeable y sin test pues no tienes un código decente y se pone hincapié en valor las entidades para no tener datos incorrectos.

seaman escribió:

Dartanyan escribió:La religion de los patrones y la sobre ingeniería en su pleno apogeo.

Cada problema tiene una solución y no todos los problemas se resuelven con la misma solución por mucho que uno crea en 'su propia' solución.

Es que los patrones de diseño son eso, soluciones que mucha gente ha usado para un mismo problema y una persona hizo una recopilación de los más útiles/famosos.
No son una regla ni una solución concreta, son un diseño y podrás adaptarlo más o menos a tu propia solución.
Seguramente muchos hayamos usado patrones de diseño sin saberlo.

Y el DDD es otra forma de crear una aplicación siguiendo una serie de reglas. Ya está.
Lo mejor del DDD es que es muy testeable y sin test pues no tienes un código decente y se pone hincapié en valor las entidades para no tener datos incorrectos.

Lo que estamos criticando no es que no se usen patrones o palabras para definir estos (que, como bien dices, todos los usamos aunque no tengamos ni idea de como se llaman comúnmente), es que las empresas y mas concretamente los entrevistadores usen como razón que no uses su modelo preferido para descartar a alguien perfectamente válido. Tu mismo has comentado que te rechazaron, haciéndote perder el tiempo, porque algo no les gustó (ni feedback te dieron), cuando estoy seguro de que eres un tío muy capaz y si la empresa requiere seguir una práctica en concreto no vas a tener problemas en hacerlo, vamos digo yo...
Esto genera en la gente una indefensión y una impotencia que a muchos nos causa rechazo. Si lo sumas a que, probablemente, alguien que use esa excusa para determinar la invalidez de un candidato tiene unas altas probabilidades de ser un capullo de narices convirtiendo ese puesto (por muy empresa top que sea) en un lugar indeseable para muchos que nuestra prioridad es que las cosas salgan y poder hacer nuestro trabajo de una forma muy digna y decente sin meternos en como programan otros.

Estoy seguro de que no soy el único que se ha cruzado con capullines en el trabajo con los que acabas discutiendo por alguna gilipollez (yo fui de esos en mis inicios hasta que entendí la programación como "filosofia") y la verdad es que no me apetece encontrármelos ya en mi futuro trabajo

Soy de los desarrolladores realmente buenos

Para empezar, te recomendaría que bajases un poco esos humos. En una entrevista se huele y, al menos para mi, es casi una red flag si se espera trabajar en equipo.

Tengo como 10 o 12 procesos abiertos

No estás buscando trabajo de camarero ni de reponedor (con todo el respeto a estos puestos), no vayas echando currículums a lo loco y selecciona un poco.

considero que, si piden pruebas técnicas es que el entorno laboral va a ser una puta mierda, con los típicos nazis

En este sector se gasta mucho tiempo y dinero en los procesos de selección y dedicarle un par de horas para demostrar tu interés y mostrar tu forma de trabajar, no lo veo un problema. Y más siendo realmente bueno, deberías poder hacerlo en menos tiempo.

Si todo va bien, vas a estar trabajando 40 horas semanales durante los próximos años y puede que sea una gran oportunidad. Dedicarle un par de horas una mañana no debería suponer un problema. Si eres bueno, no tardarás en encontrar trabajo y "gastar" tiempo haciendo pruebas.

Me da la sensación que has pasado por una muy mala experiencia y de ahí tu frustración y lo de soltar si es de nazis, cuando no tiene por qué ser así. Comentarte que yo estoy trabajando para una empresa americana conocida por todos y el proceso duró 2 meses, incluyendo pruebas técnicas y demás. ¿Fue un coñazo? Desde luego. Pero las condiciones que tengo ahora han valido totalmente la pena.

Respecto a lo del forEach, quizás simplemente es una pregunta para ver qué respondes. Tienes todo el derecho a decir que prefieres usar for...in o for...of, mientras expliques el por qué. Incluso si quieres rizar el rizo y decir que iteras los arrays hacia atrás porqué van más rápido. No se trata de decir si algo está mejor o peor, es compartir tu punto de vista con respeto.

Mucha suerte.

Buenas, normalmente no comento en este subforo, pero este hilo me ha parecido interesante. Respecto al tema principal del hilo, estoy totalmente en contra de las pruebas técnicas.

Primero, por principios. La empresa te está haciendo dedicar un tiempo determinado para ponerte a prueba, cuando tu no puedes poner a prueba a la empresa (y hay empresas en este sector que son un mojón, lamentablemente demasiadas).

Segundo, porque en muchos casos, como ya se ha comentado, te va a evaluar alguien que igual no tiene mucha idea.

La última prueba técnica que me pidieron, hace ya años, trataba de hacer una api REST en .Net con un GET básico. No lo solicitaban, pero incorporé también un sistema de autenticación mediante token para que vieran que sabía de qué iba la cosa. Les envié la prueba junto a la colección de Postman con los métodos y demás y la única respuesta que me dieron fue que le habían dicho a la chica de RRHH que no había pasado la prueba técnica. Al preguntar el motivo, no contestaron.

La cosa es que tenía un amigo trabajando allí y me confirmó que lo más avanzado que hacían en esa empresa eran Webforms, que no tenían ni idea. Y al final el motivo es que, para hacer lo que necesitaban, les valía con alguien más barato. Vamos, que me hicieron perder el tiempo para nada, y si no llego a tener a una persona trabajando allí que me explicara el motivo real, encima me hubiera pensado que había hecho algo mal...

Desde entonces, si piden prueba técnica les digo que no. Al menos en empresas españolas. Si es una empresa europea, con fama y muy buenas condiciones, ya te lo planteas... pero para las empresas patrias, ni de coña

Yo también he estado haciendo entrevistas a candidatos y, en la mayoría de los casos, charlando un rato con los candidatos, puedes ver si saben de lo que hablan o no, preguntando cosas como "¿en un caso así que harías?". Algo que no puedan tener aprendido de memoria de los libros. Evidentemente, siempre puede entrar alguien que no cumpla las expectativas, pero justamente para eso está el periodo de prueba.

Creo que es una forma también de respetar al candidato, ya que de lo contrario se está asumiendo que su tiempo no vale nada.

@[Sheer]

La verdad es que la elección de palabras no es casualidad ni fruto de la frustración ni del cabreo (bueno un poco mosca si me tiene el asunto), pero pensé que "ya que estamos en un foro, que sea entretenido" y esperaba ese tipo de reacciones del tipo de gente que tengo "calada". Con tu comentario (y de un par mas) se denota claramente la catadura moral que gastan en algunos sitios y que clase de gente tienen seleccionando...
Pareciera como si, el hecho de que un trabajador tenga confianza en su trabajo o ciertas inclinaciones hacia el sindicalismo se penalizara.

Estoy seguro de que si a un camarero (yo he trabajado de camarero) se le pidiera realizar trabajo "de pruebas" y gratuito solo para demostrar algo que, cualquier con un mínimo de experiencia y capacidad de resolución puede hacer, pondríamos el grito en el cielo, pero ya me ha quedado muy claro que determinados reclutadores no consideran a los candidatos personas, si no meros recursos de los que, en cualquier momento y según las necesidades de la empresa se van a deshacer como un trapo.

Pues no, tío... Tu empresa no merece un tiempo especial por mi parte ni voy a dejar pasar otras oportunidades porque consideres que tu empresa "americana" lo merece porque es super chachi... Tengo la suficiente experiencia como para tener caladas a los tipos de personas que suelen hacerse programadores y es uno de los entornos más tóxicos que existen precisamente por gente que tiene la cabeza tan metida en el culo que aceptan que esas prácticas sean normales, porque claro, ellos las aceptarían "si no es que no eres tan bueno...".
He trabajado con gente maravillosa con la que da gusto hacer equipo pero solo es necesario una única persona que se cree especial y con todas las respuestas como para convertir ese mismo trabajo en un absoluto suplicio, gente a la que suelen promocionar a puestos superiores precisamente para que se termine el buen rollito entre trabajadores y ellos mismos se vayan sin tener que pagar indemnizaciones.

Estos hilos valen para que los desarrolladores aunemos criterios y empecemos a poner las cartas sobre la mesa pasando de las empresas que realizan prácticas abusivas y si, una empresa que pide pruebas técnicas suele ser un lugar de mierda que, encima, suelen tirar de todas las prácticas a su alcance para joder al trabajador. Siempre son estas las que te cuelan 6 meses de pruebas (el máximo, siempre), las que realizan tácticas abusivas y se aprovechan de la ignorancia del trabajador, las que azuzan a los trabajadores para que se enzarcen entre ellos... etc, etc.

Así que no, niños, no hagáis pruebas de mierda a no ser que sea un Google y os vayan a pagar un pastizal (40K no es un pastizal).

A mi una empresa de 2 trabajadores me hizo una prueba para hacer una aplicación sencilla con datos sospechosamente reales. Cuando ya estaba por la mitad y llevaba 3 horas le dije que creía que ya había demostrado que sabía del tema, que ya podía ir decidiendo si me quería o no. El fulano se me puso todo loco, que si su tiempo valía dinero y yo se lo estaba haciendo perder con mi mierda de actitud, y que si no acababa la aplicación nunca trabajaría en su empresa (y si la acababa se la quedaría y tampoco trabajaría, seguramente). Evidentemente le dije que me parecía bien y me marché. Desde esa y otras parecidas, prueba técnica = me largo. Yo no tengo el caché que tienen otros por aquí y me parece insultante hacer pruebas de varios días, como querían muchos, para un sueldo mileurista y con 6 meses de periodo de pruebas.
No me vale la pena el estrés de un tío en el hombro cual loro del pirata mirándome trabajar, cronometrando, para que después no le guste como trabajo en ese ambiente taaaan cómodo y tan óptimo para la concentración. Además ahora muchos te hacen prueba técnica también para puestos de informático básico "me cableas esta nave, y ya decido yo si eres válido". Para eso también me hago yo "empleador". A un candidato lo pongo a desbrozar el campo, a otro a lavar el coche, a otro a limpiarme la casa.... y después a todos les digo que no cumplen.

Preséntate a alguno de esos procesos en los que exigen pruebas. Sólo a uno que realmente merezca la pena. Selecciónalo bien.

Si las pasas, verás que para ti ese filtro es favorable, y ahorrarás tiempo consiguiendo un empleo antes.

Si no las pasas, recibirás una lección de humildad que te hace falta, vista la forma en que razonas.

En este mundo siempre, SIEMPRE, hay alguien que sabe más que tú, o sabe las cosas mejor que tú, es más joven, más inteligente, más simpático, y trabaja mejor. ¿Por qué elegir a una persona en base a una recomendación cuando se la podría seleccionar con una prueba más objetiva?

Yo haría esas pruebas a ver si las paso, y si las paso, bien; y si no, lo mismo no sabes tanto ni estás tan cualificado como crees. Un profesor que tuve en la universidad, cuando nos quejábamos de la dificultad de sus exámenes, decía: "Yo me examino a diario con ustedes" y tenía razón.

Y que se presuma de la competencia de uno, pero se le tenga miedo a un examen, no revela precisamente mucha capacidad técnica.

Si de verdad crees que vales, haz esas pruebas, sin darles importancia. Tómalo como si resolvieras un crucigrama. Si duran varias horas, así miden que tienes paciencia, virtud esencial en cualquier trabajo intelectual.

El que se rinde antes del examen, ya suspendió.

Programador realmente bueno, te deseo mucha suerte con tu "estrategia" y que encuentres una empresa libre de nazis

Escipión El Africano escribió:Preséntate a alguno de esos procesos en los que exigen pruebas. Sólo a uno que realmente merezca la pena. Selecciónalo bien.

Si las pasas, verás que para ti ese filtro es favorable, y ahorrarás tiempo consiguiendo un empleo antes.

Si no las pasas, recibirás una lección de humildad que te hace falta, vista la forma en que razonas.

En este mundo siempre, SIEMPRE, hay alguien que sabe más que tú, o sabe las cosas mejor que tú, es más joven, más inteligente, más simpático, y trabaja mejor. ¿Por qué elegir a una persona en base a una recomendación cuando se la podría seleccionar con una prueba más objetiva?

Yo haría esas pruebas a ver si las paso, y si las paso, bien; y si no, lo mismo no sabes tanto ni estás tan cualificado como crees. Un profesor que tuve en la universidad, cuando nos quejábamos de la dificultad de sus exámenes, decía: "Yo me examino a diario con ustedes" y tenía razón.

Y que se presuma de la competencia de uno, pero se le tenga miedo a un examen, no revela precisamente mucha capacidad técnica.

Si de verdad crees que vales, haz esas pruebas, sin darles importancia. Tómalo como si resolvieras un crucigrama. Si duran varias horas, así miden que tienes paciencia, virtud esencial en cualquier trabajo intelectual.

El que se rinde antes del examen, ya suspendió.

Entiendo como lo planteas, pero no lo comparto. Tu estás viendo el examen desde la perspectiva de algo "teórico", pero en muchos casos el examen es práctico e incluso con resultados útiles. Si tu quieres contratar un albañil, que le preguntes cosas de su oficio, ok, hacerle que te haga una casita por la cara pues....no.
Si llevas tiempo buscando trabajo te terminas tropezando con muchos jetas, y eso aburre. Que habrá gente que por lo que sea tendrá que pasar por el aro, pero a los que tengan un CV decente, experiencia demostrable y recomendaciones de otras empresas les recomiendo no empezar aguantando chorradas y "currar gratis" desde el día uno.

Yaripon escribió:

Escipión El Africano escribió:Preséntate a alguno de esos procesos en los que exigen pruebas. Sólo a uno que realmente merezca la pena. Selecciónalo bien.

Si las pasas, verás que para ti ese filtro es favorable, y ahorrarás tiempo consiguiendo un empleo antes.

Si no las pasas, recibirás una lección de humildad que te hace falta, vista la forma en que razonas.

En este mundo siempre, SIEMPRE, hay alguien que sabe más que tú, o sabe las cosas mejor que tú, es más joven, más inteligente, más simpático, y trabaja mejor. ¿Por qué elegir a una persona en base a una recomendación cuando se la podría seleccionar con una prueba más objetiva?

Yo haría esas pruebas a ver si las paso, y si las paso, bien; y si no, lo mismo no sabes tanto ni estás tan cualificado como crees. Un profesor que tuve en la universidad, cuando nos quejábamos de la dificultad de sus exámenes, decía: "Yo me examino a diario con ustedes" y tenía razón.

Y que se presuma de la competencia de uno, pero se le tenga miedo a un examen, no revela precisamente mucha capacidad técnica.

Si de verdad crees que vales, haz esas pruebas, sin darles importancia. Tómalo como si resolvieras un crucigrama. Si duran varias horas, así miden que tienes paciencia, virtud esencial en cualquier trabajo intelectual.

El que se rinde antes del examen, ya suspendió.

Entiendo como lo planteas, pero no lo comparto. Tu estás viendo el examen desde la perspectiva de algo "teórico", pero en muchos casos el examen es práctico e incluso con resultados útiles. Si tu quieres contratar un albañil, que le preguntes cosas de su oficio, ok, hacerle que te haga una casita por la cara pues....no.
Si llevas tiempo buscando trabajo te terminas tropezando con muchos jetas, y eso aburre. Que habrá gente que por lo que sea tendrá que pasar por el aro, pero a los que tengan un CV decente, experiencia demostrable y recomendaciones de otras empresas les recomiendo no empezar aguantando chorradas y "currar gratis" desde el día uno.

Normalmente piden cosas que se puede hacer en un par de horas y eso no vale para nada.

seaman escribió:

Yaripon escribió:

Escipión El Africano escribió:Preséntate a alguno de esos procesos en los que exigen pruebas. Sólo a uno que realmente merezca la pena. Selecciónalo bien.

Si las pasas, verás que para ti ese filtro es favorable, y ahorrarás tiempo consiguiendo un empleo antes.

Si no las pasas, recibirás una lección de humildad que te hace falta, vista la forma en que razonas.

En este mundo siempre, SIEMPRE, hay alguien que sabe más que tú, o sabe las cosas mejor que tú, es más joven, más inteligente, más simpático, y trabaja mejor. ¿Por qué elegir a una persona en base a una recomendación cuando se la podría seleccionar con una prueba más objetiva?

Yo haría esas pruebas a ver si las paso, y si las paso, bien; y si no, lo mismo no sabes tanto ni estás tan cualificado como crees. Un profesor que tuve en la universidad, cuando nos quejábamos de la dificultad de sus exámenes, decía: "Yo me examino a diario con ustedes" y tenía razón.

Y que se presuma de la competencia de uno, pero se le tenga miedo a un examen, no revela precisamente mucha capacidad técnica.

Si de verdad crees que vales, haz esas pruebas, sin darles importancia. Tómalo como si resolvieras un crucigrama. Si duran varias horas, así miden que tienes paciencia, virtud esencial en cualquier trabajo intelectual.

El que se rinde antes del examen, ya suspendió.

Entiendo como lo planteas, pero no lo comparto. Tu estás viendo el examen desde la perspectiva de algo "teórico", pero en muchos casos el examen es práctico e incluso con resultados útiles. Si tu quieres contratar un albañil, que le preguntes cosas de su oficio, ok, hacerle que te haga una casita por la cara pues....no.
Si llevas tiempo buscando trabajo te terminas tropezando con muchos jetas, y eso aburre. Que habrá gente que por lo que sea tendrá que pasar por el aro, pero a los que tengan un CV decente, experiencia demostrable y recomendaciones de otras empresas les recomiendo no empezar aguantando chorradas y "currar gratis" desde el día uno.

Normalmente piden cosas que se puede hacer en un par de horas y eso no vale para nada.

Yo cobro por horas, así que que te puedo decir que por 2 horas puedo comprarme un videojuego de rebajas, una cerveza, un bocata... Para mi si vale. Y en cuanto a que en 2 horas no se hace nada pues... que no te escuche tu jefe decir eso, porque si en 2 horas no haces nada, tela.

A mi me han pedido en una prueba técnica que les haga el responsive de la web pocha en WordPress que tenían, con css. No será un curro súper cualificado, pero yo no estoy súper cualificado. Se hacerlo, puedo hacerlo, y ese trabajo vale un dinero.

Yo cuando me dicen "es para saber si sabes hacerlo" contesto: OK, pero si demuestro que se hacerlo, me lo pagas, no? Chorradas las justas.

Yaripon escribió:

seaman escribió:

Yaripon escribió:
Entiendo como lo planteas, pero no lo comparto. Tu estás viendo el examen desde la perspectiva de algo "teórico", pero en muchos casos el examen es práctico e incluso con resultados útiles. Si tu quieres contratar un albañil, que le preguntes cosas de su oficio, ok, hacerle que te haga una casita por la cara pues....no.
Si llevas tiempo buscando trabajo te terminas tropezando con muchos jetas, y eso aburre. Que habrá gente que por lo que sea tendrá que pasar por el aro, pero a los que tengan un CV decente, experiencia demostrable y recomendaciones de otras empresas les recomiendo no empezar aguantando chorradas y "currar gratis" desde el día uno.

Normalmente piden cosas que se puede hacer en un par de horas y eso no vale para nada.

Yo cobro por horas, así que que te puedo decir que por 2 horas puedo comprarme un videojuego de rebajas, una cerveza, un bocata... Para mi si vale. Y en cuanto a que en 2 horas no se hace nada pues... que no te escuche tu jefe decir eso, porque si en 2 horas no haces nada, tela.

Se lo digo cuando quieras.
En dos horas no te da tiempo a hacer una aplicación ni de coña.
Te da tiempo a hacer un fix rápido que no conlleve mucha prueba y que se tenga muy claro lo que hay que arreglar.
Tú valoras tus dos horas y no haces pruebas técnicas y lo entiendo y yo cuando me piden hacer una prueba de dos horas por entrar a un sitio donde me van a pagar 50k€ pues lo entiendo y lo hago.

Yaripon escribió:Entiendo como lo planteas, pero no lo comparto. Tu estás viendo el examen desde la perspectiva de algo "teórico", pero en muchos casos el examen es práctico e incluso con resultados útiles. Si tu quieres contratar un albañil, que le preguntes cosas de su oficio, ok, hacerle que te haga una casita por la cara pues....no.
Si llevas tiempo buscando trabajo te terminas tropezando con muchos jetas, y eso aburre. Que habrá gente que por lo que sea tendrá que pasar por el aro, pero a los que tengan un CV decente, experiencia demostrable y recomendaciones de otras empresas les recomiendo no empezar aguantando chorradas y "currar gratis" desde el día uno.

Una prueba podría ser por ejemplo poner un problema que no se pueda resolver porque faltan datos, y que el candidato te lo diga en pocos minutos.

Sobre lo que es un CV decente...si la gente dijese la verdad, no inflase sus CV, podría ser. Yo de lo que ponga cualquiera en un CV cuando no se pueda contrastar, no me fiaría.

Escipión El Africano escribió:Si no las pasas, recibirás una lección de humildad que te hace falta, vista la forma en que razonas.

Cuidado mi buen amigo canario, que ya te han 'peinao' más de una vez por el foro

exitfor escribió:

Escipión El Africano escribió:Si no las pasas, recibirás una lección de humildad que te hace falta, vista la forma en que razonas.

Cuidado mi buen amigo canario, que ya te han 'peinao' más de una vez por el foro

Un examen si está bien planteado se puede aprobar.

Si está planteado de manera maliciosa, con cuestiones retorcidas, buscando respuestas "de autor", entonces no.

Ya que me retas, te pongo un examen de informática, sobre el tipo de informática que me interesa a mí ya que trabajo en el sector público.

Para ser informático en una Administración, hay que saber de estas cosillas.

NO VALE MIRAR GOOGLE

1.- ¿Conoce usted los requisitos de accesibilidad que enuncia la norma europea UNE-EN 301 549:2019. Y que, para los sitios web, recoge las WCAG 2.1? Háblenos un poco del Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público.

2.- ¿Conoce usted el Esquema Nacional de Seguridad, aprobado por Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad? Si es así, ¿sabría usted hacer un análisis de riesgos de un servicio informático y enunciar una Declaración de Aplicabilidad?

3.- ¿Está familiarizado con las Guías del Centro Criptológico Nacional sobre seguridad en sistemas Windows?

Hala no dirás que no te lo he puesto fácil

El periodo de prueba existe, precisamente, para comprobar la validez del candidato por parte de la empresa y viceversa. Pese a las pruebas técnicas, incluso pasándolas, bien que aprovechan para que la extensión de este sea de seis meses...