Portada
mis comunidades
otras secciones
#9:
#6 O, visto de otra forma, que para entrar en esas empresas has de prepararte para escribir código chorras que en tu día a día no harás, código que se aprende en la universidad y se va olvidando y que no garantiza que la persona que los pasa tenga conocimientos más allá de pasar esa entrevista.
Yo he llegado a hacer lo contrario. Hacer una de estas chorradas, pasarla y darme el gustazo de decir que no, que con ese criterio se habrán cargado a mucha gente sin tiempo de preparar esas chorradas y habrán perdido mucho talento y que, por tanto, no quería entrar en su equipo. Por otra parte, me suelo negar a hacer una prueba de código antes de haber hablado un poco con ellos. Igual no me interesa el trabajo que ofrecen, normalmente son ellos los que me han contactado... y esperan que pierda varias horas antes siquiera de saber si me interesa lo que ofrecen?
Yo he llegado a hacer lo contrario. Hacer una de estas chorradas, pasarla y darme el gustazo de decir que no, que con ese criterio se habrán cargado a mucha gente sin tiempo de preparar esas chorradas y habrán perdido mucho talento y que, por tanto, no quería entrar en su equipo. Por otra parte, me suelo negar a hacer una prueba de código antes de haber hablado un poco con ellos. Igual no me interesa el trabajo que ofrecen, normalmente son ellos los que me han contactado... y esperan que pierda varias horas antes siquiera de saber si me interesa lo que ofrecen?
#6:
#1 No se queja, de hecho dice que se prepara uno por semana para estar en forma. Al final dice que son la manera más eficiente de cribar currículos cuando te envían 500 para una vacante y que los test están aquí para quedarse. Ya no hace falta que te leas el artículo pero está bastante interesante si os interesa el tema.
También sale un recruiter diciendo que rechazó para Netflix a uno que acabó siendo cofundador de Amazon Prime Air. La moraleja es que si os rechazan no es que seais malos, es que para ser aceptado hay que tener suerte además de habilidades. Cuando tienes 500 aplicaciones es imposible seleccionar al mejor.
También sale un recruiter diciendo que rechazó para Netflix a uno que acabó siendo cofundador de Amazon Prime Air. La moraleja es que si os rechazan no es que seais malos, es que para ser aceptado hay que tener suerte además de habilidades. Cuando tienes 500 aplicaciones es imposible seleccionar al mejor.
#42:
Hay un dicho que reza: "para el que tiene un martillo, todo son clavos".
Eso es lo que veo que le pasa a muchos desarrolladores: que se han dedicado a la programación pura, la dominan de maravilla y está super-actualizados en las últimas tecnologías, y por eso piensan que en un proceso de selección, solo les deben medir por estos criterios. Pero un programador excelente no es solo el que programa de puta madre, también debe saber comunicarse, trabajar en equipo con (¡horror!) gente que no es técnica, interesarse el negocio de la empresa para la que trabaja, planificar y organizar sus tareas, transmitir sus conocimientos a otros, mantener un ambiente positivo y constructivo, ser flexible con cambios de última hora, soportar con madurez la presión o las críticas... Y tantas y tantas cosas en las que veo a diario que fallan programadores presuntamente fabulosos. Yo en mi equipo prefiero alguien que necesita 15 minutos de consulta en Stackoverflow antes de empezar a programar nada, pero que después va a responder bien a las otras exigencias que he mencionado.
Eso es lo que veo que le pasa a muchos desarrolladores: que se han dedicado a la programación pura, la dominan de maravilla y está super-actualizados en las últimas tecnologías, y por eso piensan que en un proceso de selección, solo les deben medir por estos criterios. Pero un programador excelente no es solo el que programa de puta madre, también debe saber comunicarse, trabajar en equipo con (¡horror!) gente que no es técnica, interesarse el negocio de la empresa para la que trabaja, planificar y organizar sus tareas, transmitir sus conocimientos a otros, mantener un ambiente positivo y constructivo, ser flexible con cambios de última hora, soportar con madurez la presión o las críticas... Y tantas y tantas cosas en las que veo a diario que fallan programadores presuntamente fabulosos. Yo en mi equipo prefiero alguien que necesita 15 minutos de consulta en Stackoverflow antes de empezar a programar nada, pero que después va a responder bien a las otras exigencias que he mencionado.
#2:
Una prueba arbitraria más. Es como los tests psicológicos. Superará la prueba el que se haya preparado la prueba. La prueba no mide otra cosa.
#129:
#96 #112 Pues fueron varias razones, pero sí que pasó las dos semanas (y algo) y todas las entrevistas. Estoy hablando del año 2012, cuando Google te hacía varias entrevistas previas a ir a googleplex, y amazon todavía hacía entrevistas finales en Seattle.
Fueron varias razones, pero #96 no va tan desencaminado: 1) en todos los casos era para temas de robótica, pero le gustó mucho más el ambiente de la startup. 2) haciendo números, ya SF Bay empezaba a ser inasumible. El tiempo le ha dado la razón. Con su sueldo en Phoenix, aunque era más bajo, le dió sobradamente para ahorrar, y se han comprado un casoplón que en SF sería impensable. 3) todas las pruebas que le hicieron pasar, por otro lado, le dieron la impresión de un elitismo en ambas, que no iba con él. Todos los que le entrevistaron en google y amazon le dieron unas referencias que no le gustaron, que no iban con él.
Pero el punto es que sí hay gente que se hace todas las entrevistas y llega al final, y decide pasar, por el motivo que sea.
Fueron varias razones, pero #96 no va tan desencaminado: 1) en todos los casos era para temas de robótica, pero le gustó mucho más el ambiente de la startup. 2) haciendo números, ya SF Bay empezaba a ser inasumible. El tiempo le ha dado la razón. Con su sueldo en Phoenix, aunque era más bajo, le dió sobradamente para ahorrar, y se han comprado un casoplón que en SF sería impensable. 3) todas las pruebas que le hicieron pasar, por otro lado, le dieron la impresión de un elitismo en ambas, que no iba con él. Todos los que le entrevistaron en google y amazon le dieron unas referencias que no le gustaron, que no iban con él.
Pero el punto es que sí hay gente que se hace todas las entrevistas y llega al final, y decide pasar, por el motivo que sea.
#62:
Llevo haciendo entrevistas a candidatos, técnicas y personales, desde hace tres años en mi empresa y antes de eso estuve años ayudando a seniors a hacer entrevistas.
Gente que te llega con un currículum de la hostia, con todos los problemitas del Hackajob resueltos, que los tests de algoritmos estos los pasa con la polla... y que luego cuando firmas el contrato "porque es listo, capaz de resolver problemas, fuerte en algoritmos"... el hijodelagranputa se cae al suelo intentando hacer un endpoint de una API REST en SpringBoot, o no tiene ni puta idea de qué tipos usar en columnas SQL, o no sabe absolutamente nada de OOP y te llena los proyectos Python de la empresa de interminables listas y diccionarios cargados en memoria, haciendo programas que no aguantan un performance test, o te empastra el Git y te tienes que pasar media hora arreglando su destrozo con cherry-picks y push forces porque la ha liado pardísima.
Historias de terror de tíos superlistos de estos que saben un huevo de algoritmos y que hacen tests de algoritmos de puta madre tengo para pasarme el día entero hablando.
Por eso hace años que dejé de hacer preguntas de universidad en mis entrevistas, y me dedico a hacer preguntas de cosas que se gastan en la empresa y que se usan día a día. De poco me sirve que me resuelvas las mierdas del fizzbuzz y similares si luego no sabes OOP y abusas de lenguajes interpretados metiendo iterables y diccionarios en memoria como solución a cada tarea que se te pone en la empresa. De nada me sirve que seas el más listo de tu edad si luego no sabes trabajar con otras personas y nos dejas a los otros 10 el Git hecho una puta mierda y nos borras el trabajo.
Las estrellitas del código, a dar clases en el MIT. En la empresa mejor tener gente que sabe trabajar, y no teorizar. Gracias.
Gente que te llega con un currículum de la hostia, con todos los problemitas del Hackajob resueltos, que los tests de algoritmos estos los pasa con la polla... y que luego cuando firmas el contrato "porque es listo, capaz de resolver problemas, fuerte en algoritmos"... el hijodelagranputa se cae al suelo intentando hacer un endpoint de una API REST en SpringBoot, o no tiene ni puta idea de qué tipos usar en columnas SQL, o no sabe absolutamente nada de OOP y te llena los proyectos Python de la empresa de interminables listas y diccionarios cargados en memoria, haciendo programas que no aguantan un performance test, o te empastra el Git y te tienes que pasar media hora arreglando su destrozo con cherry-picks y push forces porque la ha liado pardísima.
Historias de terror de tíos superlistos de estos que saben un huevo de algoritmos y que hacen tests de algoritmos de puta madre tengo para pasarme el día entero hablando.
Por eso hace años que dejé de hacer preguntas de universidad en mis entrevistas, y me dedico a hacer preguntas de cosas que se gastan en la empresa y que se usan día a día. De poco me sirve que me resuelvas las mierdas del fizzbuzz y similares si luego no sabes OOP y abusas de lenguajes interpretados metiendo iterables y diccionarios en memoria como solución a cada tarea que se te pone en la empresa. De nada me sirve que seas el más listo de tu edad si luego no sabes trabajar con otras personas y nos dejas a los otros 10 el Git hecho una puta mierda y nos borras el trabajo.
Las estrellitas del código, a dar clases en el MIT. En la empresa mejor tener gente que sabe trabajar, y no teorizar. Gracias.
#114:
#71 No, no dan más grima los que corrigen.
Sí, es posible (ya te digo yo que no) que en un futuro la RAE recoja ese uso, pero los futuribles no son excusa.
Traducir "Apply for" (solicitar) como "aplicar a" y "application form" (solicitud) como "aplicación" es un barbarismo lo mires por donde lo mires y además es innecesario.
Sí, es posible (ya te digo yo que no) que en un futuro la RAE recoja ese uso, pero los futuribles no son excusa.
Traducir "Apply for" (solicitar) como "aplicar a" y "application form" (solicitud) como "aplicación" es un barbarismo lo mires por donde lo mires y además es innecesario.
#13:
#2 Sí, lo que pasa es que hay más de 1,000 problemas sólo en leetcode. Si te los preparas todos y eres capaz de resolverlos pues te has convertido en un ingeniero de la hostia.
Yo mismo estoy haciendo montones de estos problemas (y entrevistas) y sinceramente, me parece muy bien. Los algoritmos poco eficientes que pueden tener un pase en aplicaciones mono-usuario que corren en maquinones no tienen cabida en el mundo cloud donde la eficiencia tiene una conversión automática en coste. Sí, puedes hacer una puta mierda y decir a Amazon que te la escale poniendo tanta CPU como sea necesaria, pero preparate a pagar...
En Silicon Valley hay (simplificando) dos tipos de desarrolladores (ingenieros de software, como se suelen llamar): Los que controlan mucho de la tecnología de moda, y que están muy bien para empresas que empiezan un proyecto nuevo con justo esa tecnología, y los generalistas que son máquinas en código eficiente y que las grandes quieren contratar para meterles donde sea porque lo harán bien en cualquier proyecto.
No es una prueba arbitraria, es una prueba necesaria que te permite filtrar mucha morralla. Por supuesto que es un filtro que puede eliminar a buenos candidatos, pero es que es más importante asegurarte de que no contratas a ninguno malo que asegurarte de que no dejas pasar a uno bueno.
Yo mismo estoy haciendo montones de estos problemas (y entrevistas) y sinceramente, me parece muy bien. Los algoritmos poco eficientes que pueden tener un pase en aplicaciones mono-usuario que corren en maquinones no tienen cabida en el mundo cloud donde la eficiencia tiene una conversión automática en coste. Sí, puedes hacer una puta mierda y decir a Amazon que te la escale poniendo tanta CPU como sea necesaria, pero preparate a pagar...
En Silicon Valley hay (simplificando) dos tipos de desarrolladores (ingenieros de software, como se suelen llamar): Los que controlan mucho de la tecnología de moda, y que están muy bien para empresas que empiezan un proyecto nuevo con justo esa tecnología, y los generalistas que son máquinas en código eficiente y que las grandes quieren contratar para meterles donde sea porque lo harán bien en cualquier proyecto.
No es una prueba arbitraria, es una prueba necesaria que te permite filtrar mucha morralla. Por supuesto que es un filtro que puede eliminar a buenos candidatos, pero es que es más importante asegurarte de que no contratas a ninguno malo que asegurarte de que no dejas pasar a uno bueno.
#63:
Particularmente no estoy para nada de acuerdo con estos tests que voy a llamar de "algoritmia clásica", para entendernos. No se cuando a uno le ponen la chapita de "senior", pero por ponernos en contexto mi experiencia es de unos 26 años, de los cuales 16 son profesionales. Durante todo ese tiempo, de continuo aprendizaje por supuesto, sólo he tenido que rebuscar en el cajón de los algoritmos una sola vez y fue concretamente buscando optimizar la ordenación de un array, en un entorno concreto con unas características concretas.
No se... esto es como estudiar todo de memoria o estudiar razonando las cosas... razonar las cosas te da la capacidad de aprender a investigar por tu cuenta, y de buscar soluciones activamente. Aprender las cosas como un papagayo, particularmente pienso que es una pérdida de tiempo.
Y volviendo a la cuestión, estoy completamente de acuerdo con #42... no quiero genios en mi equipo.
No se... esto es como estudiar todo de memoria o estudiar razonando las cosas... razonar las cosas te da la capacidad de aprender a investigar por tu cuenta, y de buscar soluciones activamente. Aprender las cosas como un papagayo, particularmente pienso que es una pérdida de tiempo.
Y volviendo a la cuestión, estoy completamente de acuerdo con #42... no quiero genios en mi equipo.
#5:
La voy a menear por el interesante debate.
Es USA. El título oficial o inoficial (senior) cada vez importa menos. El título se supone que sirve para que seas habil. Demuéstralo. Y si no tienes titulo pero eres más habil que otro que lo tiene, adelante, el puesto es tuyo.
Es USA. El título oficial o inoficial (senior) cada vez importa menos. El título se supone que sirve para que seas habil. Demuéstralo. Y si no tienes titulo pero eres más habil que otro que lo tiene, adelante, el puesto es tuyo.
#99:
#76 Es un barbarismo. El inglés "apply", usado con significado similar a "enviar una solicitud", no se traduce por "aplicar" en castellano.
http://lema.rae.es/dpd/srv/search?key=aplicar
http://lema.rae.es/dpd/srv/search?key=aplicar
#84:
#74 Pues es lo común.
Tú haces la prueba y solo conoces el rango salarial, que puede ser amplio porque es una prueba previa a la entrevista en la que hablas de temas técnicos y de la entrevista en la que negocias tu salario. Yo normalmente la cerraba si veía que era automatizada, pero ese día tenía tiempo y quería ponerme a prueba.
Tú haces la prueba y solo conoces el rango salarial, que puede ser amplio porque es una prueba previa a la entrevista en la que hablas de temas técnicos y de la entrevista en la que negocias tu salario. Yo normalmente la cerraba si veía que era automatizada, pero ese día tenía tiempo y quería ponerme a prueba.
#53:
#5 Yo hace tiempo que no uso coletillas como senior o junior, ni para referirme a mi mismo, ni para seleccionar gente, ni para referirme a gente. Utilizamos cosas del tipo "con X años de experiencia" o "con Y proyectos a sus espaldas" como "garantía" de que esa persona no es novata en el término al que se le haga referencia.
Por supuesto, tener experiencia o proyectos no garantiza que esa persona sepa moverse fuera de ese contexto. Conozco programadores Java que han estado 10 años en el mismo proyecto interminable de la administración y que saben mucho del framework propietario que se usa en ese proyecto pero que ante un proyecto nuevo u otro framework no saben ni como empezarlo.
Por supuesto, tener experiencia o proyectos no garantiza que esa persona sepa moverse fuera de ese contexto. Conozco programadores Java que han estado 10 años en el mismo proyecto interminable de la administración y que saben mucho del framework propietario que se usa en ese proyecto pero que ante un proyecto nuevo u otro framework no saben ni como empezarlo.
#45:
#7 #11 no he visto los tests pero las habilidades de un seniors muchas veces van más allá de resolver un problema algoritmico en un momento dado. Un serior (que lo sea de verdad) aprenderá mas rápido lo que le toque, se pegará mejor con la «nueva api de turno», hará una solución más escalable y pillará antes los errores, algunos incluso no se darán porque los preveerá antes de tiempo. Será mejor interlocutor y más resuelto, etc.
Obviamente en un problema algoritmico puntual pues cualquiera puede sacarlo y cualquiera puede pinchar. Como dice el artículo, pues habrá que practicar.
Obviamente en un problema algoritmico puntual pues cualquiera puede sacarlo y cualquiera puede pinchar. Como dice el artículo, pues habrá que practicar.
#30:
#15 O que asumió que un mal dia lo puede tener cualquiera, incluso los programadores, o que llamó a un número de referencias y todos le dieron una buena respuesta, o que aunque no pasó las pruebas (algunas) se notó que el tipo sabía de qué hablaba o... vamos: que un test es un fotograma, y la capacidad profesional del señor es una película entera.... Y incluso las buenas películas tienen algún fotograma malo.... Vete a saber.
#47:
#36 Comprensión lectora... justita.
Se está hablando de empresas que hacen ese tipo de pruebas, no de Netflix en concreto. De hecho, a Netflix lo menciona la persona a la que el responde, como argumento adicional para mencionar que perdieron un buen empleado que se fue a Prime porque las pruebas son una castaña y no garantizan que te quedes con los mejores, que la suerte también importa. Así que el contesta que si, que las pruebas son una tontería que puede dejar fuera a gente buena (mira, como le pasó a Netflix) y que ha rechazado algun trabajo.... no que haya rechazado a Netflix. ¿Mejor así?
Se está hablando de empresas que hacen ese tipo de pruebas, no de Netflix en concreto. De hecho, a Netflix lo menciona la persona a la que el responde, como argumento adicional para mencionar que perdieron un buen empleado que se fue a Prime porque las pruebas son una castaña y no garantizan que te quedes con los mejores, que la suerte también importa. Así que el contesta que si, que las pruebas son una tontería que puede dejar fuera a gente buena (mira, como le pasó a Netflix) y que ha rechazado algun trabajo.... no que haya rechazado a Netflix. ¿Mejor así?
Comentarios
#6 O, visto de otra forma, que para entrar en esas empresas has de prepararte para escribir código chorras que en tu día a día no harás, código que se aprende en la universidad y se va olvidando y que no garantiza que la persona que los pasa tenga conocimientos más allá de pasar esa entrevista.
Yo he llegado a hacer lo contrario. Hacer una de estas chorradas, pasarla y darme el gustazo de decir que no, que con ese criterio se habrán cargado a mucha gente sin tiempo de preparar esas chorradas y habrán perdido mucho talento y que, por tanto, no quería entrar en su equipo. Por otra parte, me suelo negar a hacer una prueba de código antes de haber hablado un poco con ellos. Igual no me interesa el trabajo que ofrecen, normalmente son ellos los que me han contactado... y esperan que pierda varias horas antes siquiera de saber si me interesa lo que ofrecen?
#1 No se queja, de hecho dice que se prepara uno por semana para estar en forma. Al final dice que son la manera más eficiente de cribar currículos cuando te envían 500 para una vacante y que los test están aquí para quedarse. Ya no hace falta que te leas el artículo pero está bastante interesante si os interesa el tema.
También sale un recruiter diciendo que rechazó para Netflix a uno que acabó siendo cofundador de Amazon Prime Air. La moraleja es que si os rechazan no es que seais malos, es que para ser aceptado hay que tener suerte además de habilidades. Cuando tienes 500 aplicaciones es imposible seleccionar al mejor.
Una prueba arbitraria más. Es como los tests psicológicos. Superará la prueba el que se haya preparado la prueba. La prueba no mide otra cosa.
Hay un dicho que reza: "para el que tiene un martillo, todo son clavos".
Eso es lo que veo que le pasa a muchos desarrolladores: que se han dedicado a la programación pura, la dominan de maravilla y está super-actualizados en las últimas tecnologías, y por eso piensan que en un proceso de selección, solo les deben medir por estos criterios. Pero un programador excelente no es solo el que programa de puta madre, también debe saber comunicarse, trabajar en equipo con (¡horror!) gente que no es técnica, interesarse el negocio de la empresa para la que trabaja, planificar y organizar sus tareas, transmitir sus conocimientos a otros, mantener un ambiente positivo y constructivo, ser flexible con cambios de última hora, soportar con madurez la presión o las críticas... Y tantas y tantas cosas en las que veo a diario que fallan programadores presuntamente fabulosos. Yo en mi equipo prefiero alguien que necesita 15 minutos de consulta en Stackoverflow antes de empezar a programar nada, pero que después va a responder bien a las otras exigencias que he mencionado.
La voy a menear por el interesante debate.
Es USA. El título oficial o inoficial (senior) cada vez importa menos. El título se supone que sirve para que seas habil. Demuéstralo. Y si no tienes titulo pero eres más habil que otro que lo tiene, adelante, el puesto es tuyo.
#2 Sí, lo que pasa es que hay más de 1,000 problemas sólo en leetcode. Si te los preparas todos y eres capaz de resolverlos pues te has convertido en un ingeniero de la hostia.
Yo mismo estoy haciendo montones de estos problemas (y entrevistas) y sinceramente, me parece muy bien. Los algoritmos poco eficientes que pueden tener un pase en aplicaciones mono-usuario que corren en maquinones no tienen cabida en el mundo cloud donde la eficiencia tiene una conversión automática en coste. Sí, puedes hacer una puta mierda y decir a Amazon que te la escale poniendo tanta CPU como sea necesaria, pero preparate a pagar...
En Silicon Valley hay (simplificando) dos tipos de desarrolladores (ingenieros de software, como se suelen llamar): Los que controlan mucho de la tecnología de moda, y que están muy bien para empresas que empiezan un proyecto nuevo con justo esa tecnología, y los generalistas que son máquinas en código eficiente y que las grandes quieren contratar para meterles donde sea porque lo harán bien en cualquier proyecto.
No es una prueba arbitraria, es una prueba necesaria que te permite filtrar mucha morralla. Por supuesto que es un filtro que puede eliminar a buenos candidatos, pero es que es más importante asegurarte de que no contratas a ninguno malo que asegurarte de que no dejas pasar a uno bueno.
Llevo haciendo entrevistas a candidatos, técnicas y personales, desde hace tres años en mi empresa y antes de eso estuve años ayudando a seniors a hacer entrevistas.
Gente que te llega con un currículum de la hostia, con todos los problemitas del Hackajob resueltos, que los tests de algoritmos estos los pasa con la polla... y que luego cuando firmas el contrato "porque es listo, capaz de resolver problemas, fuerte en algoritmos"... el hijodelagranputa se cae al suelo intentando hacer un endpoint de una API REST en SpringBoot, o no tiene ni puta idea de qué tipos usar en columnas SQL, o no sabe absolutamente nada de OOP y te llena los proyectos Python de la empresa de interminables listas y diccionarios cargados en memoria, haciendo programas que no aguantan un performance test, o te empastra el Git y te tienes que pasar media hora arreglando su destrozo con cherry-picks y push forces porque la ha liado pardísima.
Historias de terror de tíos superlistos de estos que saben un huevo de algoritmos y que hacen tests de algoritmos de puta madre tengo para pasarme el día entero hablando.
Por eso hace años que dejé de hacer preguntas de universidad en mis entrevistas, y me dedico a hacer preguntas de cosas que se gastan en la empresa y que se usan día a día. De poco me sirve que me resuelvas las mierdas del fizzbuzz y similares si luego no sabes OOP y abusas de lenguajes interpretados metiendo iterables y diccionarios en memoria como solución a cada tarea que se te pone en la empresa. De nada me sirve que seas el más listo de tu edad si luego no sabes trabajar con otras personas y nos dejas a los otros 10 el Git hecho una puta mierda y nos borras el trabajo.
Las estrellitas del código, a dar clases en el MIT. En la empresa mejor tener gente que sabe trabajar, y no teorizar. Gracias.
Se queja de que le ponen tests de algoritmos y no los pasa. Pues toca estudiar. Lo que le pasa es que por ponerse la coletilla "senior" ya quiere que le contraten sin verfificar sus aptitudes.
#1 ahora, se premia al que mejor clona en Github.
Sin ello, no sirves.Pensar es improductivo.
Particularmente no estoy para nada de acuerdo con estos tests que voy a llamar de "algoritmia clásica", para entendernos. No se cuando a uno le ponen la chapita de "senior", pero por ponernos en contexto mi experiencia es de unos 26 años, de los cuales 16 son profesionales. Durante todo ese tiempo, de continuo aprendizaje por supuesto, sólo he tenido que rebuscar en el cajón de los algoritmos una sola vez y fue concretamente buscando optimizar la ordenación de un array, en un entorno concreto con unas características concretas.
No se... esto es como estudiar todo de memoria o estudiar razonando las cosas... razonar las cosas te da la capacidad de aprender a investigar por tu cuenta, y de buscar soluciones activamente. Aprender las cosas como un papagayo, particularmente pienso que es una pérdida de tiempo.
Y volviendo a la cuestión, estoy completamente de acuerdo con #42... no quiero genios en mi equipo.
#6 Ya hay que ser un friki del móvil para tener instaladas 500 aplicaciones.
#24 Creo que te equivocas:
https://dle.rae.es/?id=3CjZzQU
No viene recogido como en desuso. No est'a en "desuso", sino que no tiene ese uso en espa;ol. Lo que est'a haciendo es usar un barbarismo, y una barbaridad, al mismo tiempo
#6 Por qu'e lo llamas aplicaciones?
#15 O que asumió que un mal dia lo puede tener cualquiera, incluso los programadores, o que llamó a un número de referencias y todos le dieron una buena respuesta, o que aunque no pasó las pruebas (algunas) se notó que el tipo sabía de qué hablaba o... vamos: que un test es un fotograma, y la capacidad profesional del señor es una película entera.... Y incluso las buenas películas tienen algún fotograma malo.... Vete a saber.
#51 cuenco de arroz y 1 euro al mes.
Esas pruebas técnicas sirven para eliminar a mucha gente que va de desarrollador porque ha hecho el hola mundo. Prueban que tienes la capacidad para enfrentarte un problema en poco tiempo y dar una solución. Pasado ese corte, hay otras cosas que influyen más a la hora de seleccionar candidatos, y ya ahí depende del entrevistador, puesto, experiencia, etc.
#7 #11 no he visto los tests pero las habilidades de un seniors muchas veces van más allá de resolver un problema algoritmico en un momento dado. Un serior (que lo sea de verdad) aprenderá mas rápido lo que le toque, se pegará mejor con la «nueva api de turno», hará una solución más escalable y pillará antes los errores, algunos incluso no se darán porque los preveerá antes de tiempo. Será mejor interlocutor y más resuelto, etc.
Obviamente en un problema algoritmico puntual pues cualquiera puede sacarlo y cualquiera puede pinchar. Como dice el artículo, pues habrá que practicar.
#5 Yo hace tiempo que no uso coletillas como senior o junior, ni para referirme a mi mismo, ni para seleccionar gente, ni para referirme a gente. Utilizamos cosas del tipo "con X años de experiencia" o "con Y proyectos a sus espaldas" como "garantía" de que esa persona no es novata en el término al que se le haga referencia.
Por supuesto, tener experiencia o proyectos no garantiza que esa persona sepa moverse fuera de ese contexto. Conozco programadores Java que han estado 10 años en el mismo proyecto interminable de la administración y que saben mucho del framework propietario que se usa en ese proyecto pero que ante un proyecto nuevo u otro framework no saben ni como empezarlo.
#96 #112 Pues fueron varias razones, pero sí que pasó las dos semanas (y algo) y todas las entrevistas. Estoy hablando del año 2012, cuando Google te hacía varias entrevistas previas a ir a googleplex, y amazon todavía hacía entrevistas finales en Seattle.
Fueron varias razones, pero #96 no va tan desencaminado: 1) en todos los casos era para temas de robótica, pero le gustó mucho más el ambiente de la startup. 2) haciendo números, ya SF Bay empezaba a ser inasumible. El tiempo le ha dado la razón. Con su sueldo en Phoenix, aunque era más bajo, le dió sobradamente para ahorrar, y se han comprado un casoplón que en SF sería impensable. 3) todas las pruebas que le hicieron pasar, por otro lado, le dieron la impresión de un elitismo en ambas, que no iba con él. Todos los que le entrevistaron en google y amazon le dieron unas referencias que no le gustaron, que no iban con él.
Pero el punto es que sí hay gente que se hace todas las entrevistas y llega al final, y decide pasar, por el motivo que sea.
#76 Es un barbarismo. El inglés "apply", usado con significado similar a "enviar una solicitud", no se traduce por "aplicar" en castellano.
http://lema.rae.es/dpd/srv/search?key=aplicar
#11 https://leetcode.com/problemset/all/?difficulty=Hard
Ponte con algunos, cuando hayas resuelto 5 ó 6 me lo dices
He entrevistado a decenas de programadores en los últimos años y los tests son simplemente una herramienta para tener código que ha escrito él candidato y tener algo sobre lo que hablar.
Deben ser algo sencillo, que no se atasque si no es alguien muy básico.
Además, los tests tienen que ser siempre hechos a medida de la empresa, para que sean únicos.
#9 No entiendo el “gustazo” de perder tiempo haciendo pruebas para al final rechazarlo. Piensa que a ellos les importa una mierda no se van a sentir aleccionados ni nada de eso. Pero si tú te sientes bien yo me alegro mucho eh.
#71 No, no dan más grima los que corrigen.
Sí, es posible (ya te digo yo que no) que en un futuro la RAE recoja ese uso, pero los futuribles no son excusa.
Traducir "Apply for" (solicitar) como "aplicar a" y "application form" (solicitud) como "aplicación" es un barbarismo lo mires por donde lo mires y además es innecesario.
#6 #9 Acabo de por eso durante 3 meses. Lo que quieren es que pagues LeetCode Premium e InterviewCake (casi 500€ de golpe este ultimo).
He debido de hacer 1-2 tests de esos por semana durante 3 meses (los primeros los de Google y Facebook, que son los que introdujeron esta mierda), para que me acabe contratando una empresa que no hace de eso.
#1 Lo que pasa es que cuando ya tienes un trabajo que te ocupa 50-60h a la semana, lo de estudiar autenticas chorradas no resulta tan sencillito
#6 Corrección amistosa: traducir apply por aplicar es un false friend. Solicitudes estaría mejor.
#74 Pues es lo común.
Tú haces la prueba y solo conoces el rango salarial, que puede ser amplio porque es una prueba previa a la entrevista en la que hablas de temas técnicos y de la entrevista en la que negocias tu salario. Yo normalmente la cerraba si veía que era automatizada, pero ese día tenía tiempo y quería ponerme a prueba.
#36 Comprensión lectora... justita.
Se está hablando de empresas que hacen ese tipo de pruebas, no de Netflix en concreto. De hecho, a Netflix lo menciona la persona a la que el responde, como argumento adicional para mencionar que perdieron un buen empleado que se fue a Prime porque las pruebas son una castaña y no garantizan que te quedes con los mejores, que la suerte también importa. Así que el contesta que si, que las pruebas son una tontería que puede dejar fuera a gente buena (mira, como le pasó a Netflix) y que ha rechazado algun trabajo.... no que haya rechazado a Netflix. ¿Mejor así?
Puede que estos tests estén para quedarse, pero tal y como dicen, no sirven realmente para discernir a alguien apto para el puesto. Imponer una prueba física compleja sería otro modo "eficiente" de hacer una criba sobre esos 500 candidatos. Parece una manera de hacer perder el tiempo a candidatos preparando unos ejercicios que raramente usarán en su día a día; quizá buscando a quienes han salido recientemente de alguna formación donde se enfocaban en ese tipo de problemas teóricos.
#9 En mi caso les perdí el respeto a estas prueba desde que vi que en una startup entró alguien que demostró ser bastante inútil en nuestro equipo. Y sin embargo utilizaban este tipo de pruebas, de modo que descartaron a otros que parecían sacar trabajo técnico de cierta calidad.
#7 he mirado los test (hay uno de prueba) y la verdad que van a pillar pero vamos es que si la cagas en el codigo de esa manera que algo falla, muy senior no eres cuando no eres capaz de pasar esos 3 tests
La mejor solución es un reto sencillo para implementar algo que el candidato debería saber.
Es el sistema que yo uso.
Además se puede semiautomatizar la evaluación.
En cuanto a algoritmos, jamás tuve que codificar ninguno complejo en 12 años. Lo que hay que hacer es entenderlos, llegado el momento
#9 No, tú no has rechazado un trabajo en netflix bay area por +200.000€
ni tú ni nadie que no trabaje ya allí. Y si lo haces, tampoco te pones a hacer el imbécil de pasar pruebas para rechazarlas por los loles
#110 pues no la haces y pasas de largo, si no cumple fuera a no ser que tengas referencias de la empresa y lo necesites.
que siempre hay cafres y también depende de lo que puedas ofrecer, pero vamos, que a día de hoy es muy fácil filtrar.
#93 Ahí estás equivocado, hay muchas empresas que, siquiera antes de dedicarte 5 minutos a contarte su rollo (que entienden que lo ha hecho el recruiter), van y te sueltan un filtro inicial de prueba de código. Tantas, que en los últimos 4 años, ya hubo más entrevistas donde querían que pasase dicho filtro, sin hablar nada con ellos.
En una llegamos a la entrevista en persona, no había cruzado ni una palabra con ellos más allá de "hola, como estás", y me metieron en una sala, me dieron un problema de distribución, y me dieron una hora para hacerlo, y se fueron.
A los 2 minutos, me levanté, salí de la sala, fui por recepción y les dije que me iba, que muchas gracias. Ni llamaron. El recruiter era la primera vez que trabajaba con ellos y se quedó pasmado.
Como comprenderás, igual que está diciendo #72, sin conocer la empresa o al menos que me vendan su humo, pues en algunos casos no me da la gana dedicar mi tiempo sin que ellos se hayan molestado en lo mismo, antes. No se trata de vender el oro y el moro, se trata de que me cuenten sus valores, qué están buscando y qué esperan de mí como profesional y persona, que me cuenten de su día a día, la organización del trabajo, etc.
#1 el autor parece un poco llorica, en plan hice uno y ahora es un problema global, pero a ver cuantos de esos algoritmos necesita un programador en su día a día, es una prueba absurda en muchísimos casos (en otros quizás necesaria)."En el test te pedimos implementar el breadth-first, pero el trabajo es retocar plantillas de wordpress"
El problema es que nadie tiene muy claro cual es un buen método de entrevistar a posibles candidatos, es muy caro y gasta mucho tiempo y recursos. Estos tests es una solución cómoda (tus trabajadores no tienen que revisar el trabajo de los candidatos, ahorras tiempo de entrevista, eliminas candidatos,...). Desde mi punto de vista hay peores métodos (los hay que te piden que arregles algun bug de su código directamente y les envies 3 PR, o pruebas de 2-3 dias mínimo) y también los hay mejores (pruebas más relacionadas con la empresa en pair-programming)
PS: mi último trabajo lo obtuve sin que me hicieran ninguna prueba
#56 yo conozco a alguien que rechazó a google y amazon, tras 7 y 5 entrevistas, como 2 semanas en entrevistas y conversaciones con ellos, para irse a una startup en phoenix. Si, phoenix, ese sitio que a la gente cool de California y bay area le suena a puto pueblucho.
El recruiter interno de google llegó a decirle si estaba out of his mind. El de amazon se rió de él. Tal cual.
#9 Perdona, se me ha ido el dedo al negativo sin querer , lo compenso con positivo en otro comentario
#13 No, si los completas todos te has convertido en un tipo que sabe ordenar eficientemente vectores en una hora, algo que casi cualquier otro empleado válido sabrá hacer en hora y media, con esa media hora para repasar los conceptos teóricos que requieren esos ejercicios y que, si estás trabajando, no los recuerdas al dedillo.
Ahora bien, quién pasa esos ejercicios? Quien no trabaja y se prepara ejercicios de ese tipo durante varias horas al día o quien es bueno en su trabajo y está experimentando con nuevas tecnologías y nuevos paradigmas de programación, no preocupándose de prepararse entrevistas precisamente porque es bueno y no le falta trabajo?
#179 Los conceptos son fundamentales, programar un binary tree contra reloj no lo es. Si quiero que alguien me resuelva algo contra reloj, quiero que al menos parezca un problema real y ver como lo descompone y lo analiza. Las estructuras de datos están en Internet y en una entrevista veo rápidamente si las conoce o no, y si las conoce sabrá implementarlas una vez las haya repasado.
Al final es lo de siempre: Quieres gente que se haya preparado para el trabajo o para aprobar el examen? Más cuando quien sabe hacer el trabajo ya no se prepara el examen de nuevo.
#229 Tranquilo, Google apenas tiene desarrollo en Europa, casi todo son tareas de soporte, así que el que alguien "este de entrevistas" con ellos no me impone respeto. Eso sí, es muy corporativo. Con 3 empleos en dos años más bien te pasarán a una subcontrata. Amazon, según en que equipo caigas, pero puedes hacerte ilusiones, de hecho la parte española se ha hecho infame en la comunidad expat porque se dice que están buscando a gente tan desesperadamente que contratan a cualquiera que sepa inglés, igual tienes suerte. Si lo haces en un equipo de Dublín, que es el único lugar europeo donde hay algún desarrollo puntero de Amazon, verás como se hace una entrevista de verdad. Salvo que todo lo que me has contado sea un invent, claro. Porque lo de solo dos años de experiencia sin carrera en un registrado en 2007 me da que o bien te registraste a los 10 años o bien entraste tarde en el sector, ambas cosas que no me cuadran por distintos motivos.
Por lo demás, lo que dices me suena a inventos descarado.
#232 Eso no es estar de entrevistas eso es el contacto previo Hulio. Eso es spam del recruiter que se lleva un bonus si te contratan y lo envía a todo perfil que ve que más o menos se parece para que un tipo que sabe te detecte en los primeros 10 minutos de la llamada o que incluso ni se moleste en llamarte.
Te tiraron para atrás de Amazon es? Debes de ser el primero en meses, o eso o confirmas mis sospechas de como programas. Amazon en España podría tirarte para atrás si eres muy malo, pero por company fit no he oido un solo caso.
Deja de hacerme reír.
#18 #26 #35 #41 Sin acritud, ¿sabéis que dais más grima los que corregís a los que dicen aplicar que los que usan la palabra, verdad?
Lo habéis entendido perfectamente y es sólo cuestión de tiempo que sea aceptada por la RAE, si no lo está ya.
#16 no conocía esto. Me encanta. Muchas gracias!
#42 Exacto. La tecnología se aprende, la actitud no tanto. Es mejor tener a una persona que sabe jugar en equipo y que tiene inquietud por aprender y aprende rápido (que no aprender+olvidar rápido), que un lobo solitario que dice que hace las cosas "porque así las hago yo que lo hago mejor" y no cambia de actitud. (Lo de si lo hace mejor o no de verdad, esta abierto a discusión y una de las dos partes tendrá que corregir la manera de hacerlo).
#25 Alguien se inventa los algoritmos. Entenderlos es lo mínimo para ser un programador decente.
Para trabajar en Google no es suficiente.
#104 No, no.
Este en particular me contactó el recruiter de la empresa por LinkedIn, dije que no buscaba activamente pero estaba abierto a hablar de ofertas, me dijo que sin problema, que me llamaba para una entrevista y... Zasca! prueba al canto. De ahí mi cabreo y el hecho de completar la prueba para poder decirles cuatro cosas en la entrevista telefónica posterior.
Cuando era yo el que buscaba filtraba según lo que me interesase trabajar en la empresa y el tiempo que me dijera el recruiter que duraba la prueba.
#77 Cuando alguien escribe "recruiter", espero y deseo que en el Apocalipsis Zombi se encuentre con Lázaro-Carreter, María Moliner, o Arturo Pérez-Reverte (zombi o vivo).
#71 Me da igual que te d'e grima a ti o a cualquier otra persona que defienda hablar mal.
#20 Esto parece un análisis sobre el mercado laboral de España. No es extrapolable a la situación en USA y menos a compañías grandes, como las que menciona el artículo (Netflix).
En el artículo del meneo se mencionan las pruebas técnicas teóricas sobre algoritmos (análisis de complejidad, optimización, etc). En el artículo que pasas hablan de la cultura de empresa y de que hay candidatos que usan eso para descartar. Lo cual es otra cosa diferente y quizá el autor del artículo también lo aplica, pero no es su enfoque.
Dicho esto, hay empresas más o menos reciente con "cultura de empresa" que se inmiscuye demasiado en sugerir actividades o decir qué debe o no debe hacer el empleado. Desde sugerir una visión política hasta lo típico de fomentar más o menos machaconamente unas actividades en conjunto para hacer "team building" o "sugerencias" para que un empleado se identifique con la empresa, a dar cursos entre empleados o compartir experiencias de uno a otros, a quedar X días entre semana o incluso en fin de semana, etc.
A a alguna gente le parece bien y motiva que le propongan actividades y le den todo eso hecho, y a otros nos disgusta tanta intervención empresarial en las relaciones y actividades y preferimos definir nosotros qué hacemos y con quién. Y esto hace que cada cual se decante por un tipo de empresa u otro.
#65 Ese es otro tema. Si al menos demuestran que gastan en la entrevista el tiempo que tú inviertes es razonable que quieran ver cómo trabajas. Yo estoy en contra de tener que demostrarles algo "solo" a ellos sin nada a cambio. No tengo nada en contra de las pruebas, solo en contra de las pruebas automatizadas de "combina estos numeritos y estás letritas dentro de este método y pasamos los unit tests para ver si vales) porque por experiencia no demuestran capacidad resolutiva y son una criba que ya ha cribado a los que no tienen tiempo de preparar entrevistas, tal vez porque dedican su tiempo a resolver problemas reales
#70 La de los que exigen eso. Ellos dicen que tienen 500 candidatos, pero también hay un número de empresas. ¿Quieres que te demuestre que soy el candidato que quieres sin que tú a cambio me vayas a demostrar que tengo que perder cuatro horas con tu empresa en lugar de con la de al lado?
#93 No, nadie lo ha dicho, pero lo he vivido. Que te digan que te van a entrevistar, reserves un tiempo para la entrevista, te metas en casa con todo cerrado para que no haya ruido de fondo, mires su web para ver lo que hacen y qué preguntarles, te llamen y te digan "lo primero es que pases el test que te mandamos a tu correo, hale, hasta luego".
Tengo algo más de 8 años de experiencia, certificado hasta las trancas (AWS Pro, GCP, Big Data, Scrum, CKA, etc). Trabajo con Java, Python, Go, .Net, C#, etc. He trabajado en empresas de Austria y Alemania. Y aún así, siempre que cambio de trabajo o tengo idea de hacerlo (cada 2-3 años lo he hecho), me suelo tirar 2-3 meses antes preparándome las entrevistas y las pruebas de código en sitios como hackerrank, leetcode o interviewcake.
Si es cierto que algunas entrevistas suelen ser más suaves, si alguien con quien he trabajado está en la empresa, o teóricas si el puesto es más de arquitectura o de management. Pero yo veo estupendo que haya pruebas de código.
#36 yo también he rechazado buenas ofertas sólo por el hecho de hacer procesos de selección como entrenamiento.
#6 500 candidatos*
Muchas veces tengo la sensación de que este tipo de pruebas sólo están para satisfacer el ego de los entrevistadores. Si la gente no las pasa, entonces es que ellos tienen el nivel muy alto y pueden considerarse una especie de pioneros elegidos. Tan simple como eso.
#6 Cuando tienes 500
aplicacioneses imposible seleccionar al mejor.Solicitudes, candidatos, aspirantes...
#232 Y antes de cagarla repasa la diferencia entre engineering y development en empresas como Amazon. Si realmente fueses un "crafter" como dices, estarías buscando roles de developer puro.
Como dice al final, cuando tienes 500 candidatos hay que poner filtros, aunque sean arbitrarios, entre todos los que cumplen requisitos. Es imposible entrevistar a todos.
Si como le pasa a mi empresa , buscas perfiles técnicos bastante especializados, y no pagas más que el resto, pues te toca pasar de pruebas estúpidas y entrevistas a todos los que se presentan.
#71 "Aplicar" suena tan terriblemente mal que preferiría estar una hora delante de una persona arañando una pizarra.
#14 Esa tarea la efectúan perfectamente los partidos políticos. Pero buena idea.
#16 Oye, pues tiene tests que molan. El del laberinto me lo apunto para hacer un día que esté muy aburrido. Al menos resuelves un problema más o menos real.
Luego están los de "combina dos arrays" o "convierte un arbol N en uno binario" que parecen ejercicios salidos de clase de estructura de datos, en los que es lógico que se quiten a la gente con experiencia que lleva mucho tiempo sin hacerlo. Por alguna razón he visto que mayoritariamente escogen el segundo caso, y ahí solo puedo pensar que lo hacen porque quieren quitarse a gente que no se ha preparado exclusivamente para hacer entrevistas o no tiene recientes los conocimientos de esta estructura de datos. Claro, son conceptos que recuerdas en una hora de lectura, pero si no estás dedicado a hacer entrevistas no tienes esa hora.
#6 Siguiendo con mi carrera de talibán traductor, decirte que en este contexto "application" se traduce por "solicitud (de empleo)". Lo de aplicación duele.
Más pronto que tarde la IA solucionará casi cualquier problema que se le proponga y sobrarán el 99% de los desarrolladores.
#40 Yo vivo en el extranjero, hablando ingl'es todos los d'ias, y trato de evitar hablar mal el espa;ol.
#42 Normalmente esa es otra parte de la entrevista. La técnica por un lado y la personal por otro. Pero sí, cuánto friki hay que aguantar por no haber entrevistas personales bien planteadas.
#71 Ni lo está, ni lo va a estar.
#42 Toda la razon, estoy arto de ver frikis que trabajan en trincheras, sin relacionarse con nadie. No creo que las empresas que tengan en sus plantillas estos trabajadores sean las que pueden progresar mas, lo que hace falta es trabajo en equipo y no semi dioses engreidos.
#22 Cuando la empresa tiene su propio gimnasio, guardería, máquina expendedora de powerbanks, cenas gratis... Lo que busca es que no tengas otra vida fuera de la empresa.
Tanto para que hagas todas las horas extra posibles, como para que no te quieras ir de la empresa al ser toda tu vida.
#32 uno que echaron de Google escribió un artículo sobre el impacto que tuvo el que de pronto perdiera todo eso. No te echan del trabajo, te echan de tu vida.
#1 pues sí, pero esos test lo que comprueban es que sabes resolver un algoritmo pequeño (tres en una hora) pero no evalúan si, por ponernos en lo trivial, sabes organizar los directorios del proyecto para que el instalable no dé puta pena. Y de ahí para arriba, que una jerarquía de clases con sus interfaces, sus virtuales/abstractas, auxiliares, etc, no se hace en un ratito.
Bueno, pues el "senior" del "senior developer" va más de lo segundo que de lo primero.
PD: Y en anglosajonia lo de "developer" quiere decir "desarrollador+analista+arquitecto+loquehagafalta"
#6 Ese que acabó en Amazon también tendría que pasar varias pruebas allí. Me imagino que se puso a estudiar, o tuvo suerte y le tocó algo que se había mirado.
#5 en España eso es impensable
#62 Efectivamente, los test académicos chorras servirán para contratar a alguien con nula o poca experiencia, pero para seniors lo que vas a hacer es descartar a gente perfectamente válida, y encima se te cuelan flipadillos.
#9 Tu día a día no es el de un ingeniero de Netflix.
#75 bueno hablaba en general no en informática.
Supongo, que no lo sé, que precisamente las informáticas pueden ser de las más pragmáticas en ese aspecto.
Ojo, que tampoco digo ahora que un autodidacta pueda hacer de médico sin título o algo así
#13 piensa bien tu afirmación: pero es que es más importante asegurarte de que no contratas a ninguno malo que asegurarte de que no dejas pasar a uno bueno
No, no y definitivamente no. Contratar un mal empleado tiene remedio, pero perder un buen empleado es irremediable.
#182 Pues por eso España no es Silicon Valley.
Sigue dedicado a la GESTIÓN.
#126 Contratar un mal empleado tiene mal remedio. Para empezar porque tienden a multiplicarse y a contratarse entre ellos.
Dejar pasar un buen empleado suponiendo que contratas a otro igual de bueno no es ningún problema.
#141 ¿en la carrera haces 5,000 problemas? Pues enhorabuena a tu universidad.
Es fácil, vete a leetcode e intenta resolver los problemas, no es más.
Y claro que me puedes poner mil problemas que yo no puedo resolver. ¿y? Eso habla de mi nivel, no del tuyo.
#186 ¿pero qué ordenar vectores? Todo el mundo sabe ordenar un vector o puede aprender en un rato. Eso es un problema de nivel fácil.
Los problemas complicados son los que ni siquiera sabes que estructura de datos es la mejor, o en los que los datos de entrada son un array con 10 millones de elementos con los que tienes que hacer algo en un programa que termine su ejecución en no más tiempo que lo que se tarda en recorrer el array (es decir, no lo puedes recorrer dos veces), no puedes usar memoria auxiliar, etc.
El trabajo de muchos ingenieros de software en Silicon Valley son algoritmos supereficientes todo el día. No es programación "de batalla" a la española. Cuando estás trabajando en software que tiene que escalar a millones de personas y cada una de esas personas tiene un coste la eficiencia es lo más importante.
#196 Oye, pues niegate.
Estos ejercicios sirve para demostrar que sabes cual es la mejor estructura de datos para cada problema, y eso claro que es contra reloj, si te parece para cada cosa te estás un rato en stackoverflow mirando como hacerlo.
También sirven para demostrar que eres capaz de comprender el problema.
Si te parece que no poder usar tu propio IDE para una pregunta meramente algorítmica cuya solución óptima son menos de 20 líneas de código, pues está claro que no eres lo que buscan. No lo que no es ningún problema, tu sitio no es Google y ya está, hay montones de empresas de otro tipo donde la eficiencia algorítima no es lo más importante.
#200 ¿pero tú de donde sacas que estas pruebas son automatizadas? No, no lo son, yo nunca he dicho que lo sean. Pero son de este tipo (y te aseguro que sé lo que digo) para empezar a hablar. Si no sabes hacer un programa eficiente en los minutos de entrevista, lo demás da igual. No te van a pedir que hagas un interfaz de usuario bonito o un diseño de un gran sistema en el primer filtro.
#202 Pongo ejemplos de leetcode porque es una web dedicada a practicar problemas *como los que salen en las entrevistas* .
Literalmente los mismos de hecho en muchos casos. En leetcode puedes leerlos, dedicarles tiempo, implementarlos, probar tu código, etc. Ese es el valor de leetcode y por eso es tan popular entre los que que quieren trabajar en las grandes.
Las primeros filtros por otro lado son siempre telefónicos (te aseguro que llegar a visitar una empresa en persona ya es un logro que implica que has pasado dos o tres filtros) y te vas a encontrar una web tipo codepad si tienes suerte un te van a pedir que escribas en un Google Docs sin compilador y sin nada.
#60 todas, absolutamente todas las de ese calibre hacen pruebas de código. No te mandan a hacknewbs.com a resolver 3 problemas, te dan un tiempo y varios personalizados mientras te controlan por escritorio remoto si estás en otra ciudad y vas hablando con ellos sobre tu forma de resolver los problemas.
El hecho es que es más avanzado pero el filtro es el mismo, entrevistas de código. Sólo que en esa clase de empresas, tratan de evitar los "cracking the code interview" y te plantan cosas aún más jodidas y menos genéricas.
Pero como digo, ni dios te va a contratar sin entrevistas de código y problemas similares sólo porque en un papel escrito por ti diga que has trabajado en otra empresa y eres senior, y si no eres un chaval de 18 años, tampoco te van a pedir un github como si no tuvieses vida fuera de programar.
Es una manera como otra de cribar candidatos pero eso no implica que sea un buen método.
De hecho, que existan plataformas especializadas y que los programadores dediquen horas a preparar las pruebas pervierte la finalidad de éstas. Quien saca mejor nota en la oposición de neurocirugía no es el mejor neurocirujano, es el que más se ha preparado el exámen.
El problema oculto de esto es que habrá hordas de desarrolladores "gastando" su tiempo de formación en aprender algoritmos que en el mejor de los casos utilizarán en el 0,001% de su vida laboral y cuya finalidad es pasar los procesos de selección, cuando podrían dedicarlo a mejorar otros aspectos que utilizan en el 99% del tiempo.
#203 Entonces llevamos mucho tiempo hablando de sistemas diferentes de entrevista, y estamos más o menos de acuerdo en el correcto.
Yo me encontré muchos casos, y te aseguro que siguen existiendo y cada vez son más extendidos, de empresas que te envían a webs que te ponen ejercicios de este tipo con una cuenta atrás (20 minutos, 10 minutos, 1 hora...), y que luego hay unos unit tests que no ves y que te dicen que has pasado o que no, sin que a nadie le importe cómo has trabajado, por qué lo has hecho bien o por qué lo has hecho mal. Esos son los sistemas que critico, y leetcode me había parecido uno de esos.
Contra el caso del que hablas no tengo nada. Es más, cuando yo entrevisto también me gusta poner algún ejemplo práctico para ver como se desenvuelve el entrevistado, y cuando me toque volver a ser el entrevistado espero que haya al menos un par de retos técnicos en la empresa a la que quiera ir.
#218 Eso no es frecuente donde estoy.
Negocias el salario en la última entrevista, por lo que la oferta final suele ser algo que vas a aceptar, o, si ven que no vas a aceptarla, directamente no te la hacen.
#220 No necesariamente. Si el sueldo que has dicho que pides es menor que el que ellos ofrecen, y en la negociación te sugieren que es muy alto para ellos y tú dices que no aceptas menos, no van a entrar en el juego de hacer ofertas para ver si cuela. Si no aceptas una oferta que has dicho que aceptarías, quedas muy mal y es casi seguro que no te harán otra En España es frecuente que se haga, en otros países no tanto. Igual que antes he dicho que tengo mi tiempo en mucha estima, los de recursos humanos y cuentas de esa empresa también tienen el suyo, y no van a perder el tiempo conmigo si ven que estoy jugando con ellos.
#222 Ya te digo lo que te vas decir el curso: Que ignorando la concurrencia mejoraría la eficiencia de los que están preparados para ellos, que las estructuras que hay por defecto podrían ser más eficientes para un límite X de datos y otras para un límite y. . Dudo muchísimo que digan que una estructura cualquiera programada dentro de la JVM es peor que otra que puedas programar en Java. En todo caso, que en unas determinadas condiciones podrías hacer una que a ti te funcionase mejor, y eso casi nunca va a ocurrir.
Alternativa? Una entrevista de verdad, donde el que te pregunte sepa identificar tus conocimientos sin necesidad de que un programita te diga si has tenido un buen día.
Tú consideras trabajar internacionalmente, yo lo hago. Y no, ya hace mucho que no trabajo en cárnica. Es más, tu mentalidad es la que vi en la cárnica y de la que hui. En Linkedin, lo primero que van a hacer, es pedirte el cv tras contactarte.
"Empresas top"? No me digas más, líderes del sector. Espero que sí te planteas trabajar internacionalmente como dices te hagas contractor, porque tres empresas en solo dos años es una red flag para alguien buscando permanent. Lo mismo que pasar meses vacíos y decir que han sido para formarte. Mejor si que te fuiste a la Patagonia porque querías verla antes de que el glaciar se descongelase, porque "estoy en el paro para formarme" no cuela, y en el mercado actual no existe el paro si sabes hacer algo.
Tú consideras que tienes que demostrar algo antes de ir a la empresa. ¿Que te da la empresa a cambio? ¿Les pides su código para ver si te gustaría trabajar allí? Supongo sueno, pues entonces asumes que la empresa está en una posición de poder y que necesitas mendigarle el trabajo, cuando la realidad es que ellos necesitan empleados y el intercambio ha de ser bidireccional desde el minuto uno. Si me preguntan algo de estructura de datos, quiero que sea un humano el que esté allí, así si considera que no vale con que sepa el orden de un tree con verlo, pero se me olvida mirar el último nodo en la pizarra, entienda que sí que tengo el concepto y que simplemente no lo tengo reciente. Y si lo considera tan importante, pues adiós, los dos hemos perdido el mismo tiempo. No voy a trabajar con alguien que crea que es importante repetir algo que han hecho miles de personas antes.
#227 Craftear/maker
lol. Mucha suerte cuando entres internacionalmente. Si has aprendido machine learning busca una empresa financiera, les encanta la gente con tu perfil y es el único lugar que he visto donde cuadran. Si no aprendelo, porque no te veo en otro sector fuera de España, consultoras aparte.
#167 Seguro que sois los mismos que protestabais contra el mal uso de 'bizarro' y mira, ya está aceptado oficialmente.
Que yo sepa, no está aceptado "oficialmente". La RAE dijo hace algunos años que estudiaría incluirla en su próximo diccionario, pero finalmente no lo hizo, o al menos no veo ahora mismo esa acepción en el diccionario online. En el diccionario panhispánico de dudas sigue poniendo que debe evitarse usarla con el significado de "raro o extravagante".
En cualquier caso, "bizarro" con el significado del inglés "bizarre" está muchísimo más extendido que lo de "aplicar" para solicitar un trabajo, es prácticamente imposible que la RAE llegue a aceptarlo algún día
#86 No estoy de acuerdo. Es mucho mas importante entender conceptos de mas alto nivel, y todas las cosas que conlleva el crear y mantener sistemas. El 9X% de la codification no son algoritmos complejos. Por eso, solo para puestos concretos es util ese tipo de tests.
#170 #167 Además usando comillas simples. De vergüenza...
La mayoría de tests de algoritmos no tienen sentido alguno para validar las capacidades de trabajo de un desarrollador.
Si quieres validar si alguien vale o no, ponle una prueba real, por ejemplo un PR de una feature, o una contribución a algo open source. Ahí validas los commits, estructura el código, como entiende los requerimientos.
Lo mejor son las empresas que te hacen el test de algoritmos, y luego vas el primer día a trabajar y te ponen a arreglar un plugin de wordpress para un cliente
Yo como diferencio a un junior de un senior es que el junior aporrea el teclado y quiere programar su propia librería con clases , objetos, llena de bugs... mientras que un senior busca una librería que le resuelve el problema.
#81 Se escribe "corrige", no "corrije"... ¿me lo agradeces?
#126 Por $deity, alguien con 2 dedos de frente!!!
Estas pruebas de código se basan en perder "posibles" buenos empleados a costa de evitar a los malos (spoiler, los malos siguen llegando y consiguen entrar!), se da porque su nivel de profesionales apuntándose a las empresas es muy elevado.
Pero, en la mayoría de los casos, como bien dices, la pérdida de ese buen empleado es irremediable. El ejemplo del artículo con el ingeniero que Netflix "perdió", lo dice todo, aunque sea un caso extremo. No sólo perdieron un posible gran empleado, sino un valor añadido que otra empresa se ha llevado.
#18 Usa la voz: "aplicar" en la acepción de: "rellenar formularios". En desuso en España.
#59 lo que es escribirlo ya tal
#9 Esa superioridad moral...
Un saludo.
#52 Si tu haces esas pruebas y No sabes a que sueldo estas optando, el tonto eres tu. Nadie con 2 dedos de frente entra a un proceso de seleccion sin saber el sueldo del puesto.
#48 no es verdad. En España el título no es condición imprescindible en puestos de informática (si te refieres a un título universitario), las empresas son bastante pragmáticas en ese sentido.