EDICIóN GENERAL

Los desarrolladores senior son rechazados para trabajar (Eng)

#9 Yo voy en la direccion contraria. Me niego a entrar wn ninguna empresa que no aplique algun codetest o te hagan analisis de tus repos publicos o algo.

Son granjas de ofendiditos que lo unico que quieren es no dar un palo al agua.

Los conceptos de algoritmia y el clean code son fundamentales. Si empiezas a olvidar como resolver problemas basicos no pienses que vas a programar bien, solo sabes hacer chapucerias pegando librerias.
#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.
#186 Tambien reconozco que hay entrevistas tecnicas y entrevistas tecnicas. Y buenas y malas.

Basicamente hay dos tipos:

¿Si simplemente te meten tests automatizados? Lo normal es que te dejen usar CUALQUIER recurso y el problema se reduce a "hazme una solucion que funcione con las herramientas que conoces". En java lo tenemos facil por que tenemos muchas colecciones, pero yo por ejemplo tengo ya paquetes mios de estructuras de datos o si no se como construirlos componiendo otras estructuras aunque no sea tan eficiente.
Si usas lenguajes sin colecciones (hola C) tienes que saber implementarlo o tener alguna libreria por ahi si o si.

¿Te preguntan que lo implementes en vivo? Se razonarte un binary tree o WL tree o un trie sobre un white board y saber que expectativas puedo tener de una BD. Nadie en su sano juicio te pedira que lo implementes contra reloj excepto para ver cuan rapido eres capaz de traducirlo. Y si lo hacen, cuando lo hacen lo que buscan es ver si sabes argumentar los tradeoffs (donde el tiempo de implementacion ES un trade off, asi como los agujeros tecnicos que tengas que no vean ciertos corner cases que la experiencia te daria). Estas entrevistas ademas te van a ir cambiando los requerimientos (mas cercano a un trabajo de verdad) para que enseñes si sabes cuando puede ser optimo cambiar una estructura de datos a otra, o una arquitectura a otra, y si estas son mantenibles (facil cambio, 0 acoplamiento...)


Ahora, si te intentan mezclar churras con merinas, ya te puedo asegurar que no, la empresa no es buena.

Y prefero 40000000000 millones de veces un sistema de filtrado objetivo como "hazme este problema" donde puedes tener mas o menos suerte pero es conocimiento seguro (aka usable en todos lados) que te filtren por
-Un CV que puede estar hecho de 40K maneras y que 40K personas tienen opiniones distintas (y muy pocas saben o tienen insights reales y no prejuicios absrudos)
-Un Screening call con mr "soy tecnico pero no soy tecnico pero a ver si pillo el mayor ratio años de experiencia/dinero" y que es facil de engañar
-Referencias (lol)


Finalmente: decir que esto da para tocho post mas largo, pero si queria poner una conclusion.

No hay sistema de seleccion perfecto que no incluya el trabajo con el trabajador previo al contrato. Y esto es MUY, MUY dificil de implementar en muchos sentidos. Todo lo demas sera gamilificable o tendra resquicios ocultos con los que se puede jugar para que no sea correcto.

Hay que partir de eso siempre. Luego entramos en el terreno de los menos malos. Y, aunque lo que dices es cierto, las ventajas superan ampliamente los inconvenientes.
#192 #195 Estoy convencido de que no estamos hablando de los mismos tests.

No tengo ningún problema en que, en un momento de la entrevista en el que ya sé que me interesa la empresa, me llegue un ejercicio técnico (o incluso me den varios días para hacer uno) en el que tenga que elegir la estructura de datos, como comunicar entre distintos servicios, qué dato procesar antes... lo que sea para realizar un ejercicio. Estos ejercicios, por otra parte, los tiene que revisar una persona para ver lo que has hecho, el estilo, la limpieza...

Por desgracia, esto no es así, al menos en las pruebas que se pusieron de moda hace un tiempo y que parece que te piden hacer antes incluso de la entrevista, sin que tú puedas elegir porque te dan una web en la que poner tu código donde ni siquiera puedes usar tu IDE, tu estilo ni nada. Por ejemplo, algo que se ha puesto antes:

leetcode.com/problems/substring-with-concatenation-of-all-words/

No, me niego, salvo que sea el trabajo de mi vida, me piden que haga ejercicios de este tipo y no me apetece. Si quiero perder mi tiempo me meto en meneame, si quiero hacer algo útil buscaré algo que considere interesante, jugar reordenando numeritos y substrings para obtener una entrevista no es algo que me apetezca.Y seguro que si hago varios ejercicios similares a diario, cuando vea este lo pasaré con facilidad, pero trabajaré con la gente que ha invertido tiempo en prepararse entrevistas, por lo que está claro que ha sido gente a la que no le sobraba el trabajo. No ha cribado para quedarse con los mejores, sino que ha cribado para quedarse con los que han tenido que hacerse expertos en entrevistas, que es razonable pensar que no son los mejores sino todo lo contrario.

El trabajo de los ingenieros de Silicon Valley es tener un problema, pensarlo, evaluar qué es lo mejor e implementarlo. Estos ejercicios automatizados, al menos siempre que los he visto, han sido contrareloj y solo demuestran que tienes ciertos conceptos estadísticos y combinatorios tan recientes que los puedes usar sin tener que buscar en google.
#196 Si, si hablabamos de los mismos. Esos en lo mio eran los de segundo tipo. Los que tu dices al principio eran los de 1o tipo y es mas comun al final.

Debo reconocer que a mi personalmente es lo que mas me gusta de programar (jugar a resolver problemas con datos) y comento lo mismo. Entiendo que normalmente eso no se va a dar en un trabajo web o movil, pero OPINO (y por tanto es discutible)

1) Indican conocimiento de estructuras de programacion:
----- Ese problema es trivial usando un trie que cargue las palabras. Ser capaz de ver eso en un momento e implementarlo implica que cualquier programa que sea "encontrar mayor subconjunto de cosas relacionadas con esto" sea algo que sacas sin tener que investigar y de la forma mas optima. Y se da: buscar rutas en una lista de mapas, encontrar indice de un indice personal creado, o incluso a la hora de programar por que responde a la tecnica de diseño del Minimo Padre Comun Uso. Aunque la solucion sin trie, usando listas, tambien lo pasa (aunque es mas coñazo de programar).
----- El tener eso amueblado hace que todo aquellos que lo sepan no tienen que entrenarlo. Aquellos que no lo sepan puede entrenarlo y APRENDER eso para ser mejores programadores (aporta). Aquellos que simplemente se lo aprendan de memoria para la entrevista seran filtrados mas adelante. Aquellos que no lo aprendan es que son reaccios (generalmente) a aprender o mejorar sus habilidades.
----- Counterpoint: prefiero hacer proyectos que eso. Por esto comentaba que deberia haber una alternativa que sea mandar algun proyecto de github y tal y que sea analizado. Pero entiende que es mucho mas time consuming y, personalmente, cuando haces algo asi es por que ya "has entrado" en el proceso por networking en red.
2) Son entrenables y objetivos
----- Como comentaba antes: es infinitamente mejor para el empleado que sea un metodo objetivo el que filtre. Quieres que los metodos subjetivos te den muchisimo mas tiempo para mostrar cosas buenas que malas, y para ello, tienes que poder destacar en algo de manera objetiva.
----- El entrenamiento no es costoso. Leerse "Cracking the code interview" se puede hacer en unas 4 horas. No tienes ni que hacer los problemas: piensalos, y si no lo sabes mira la respuesta. Si quieres entrenar, metete a algun concurso de verdad o ponte a hacerlos, y aun asi no te deberia llevar mas de 30 minutos a la semana (o si alguno te cuesta y aprendes algo nuevo, nice).
----- Y creo que no es discutible que esto es preferible a los lectores de CV automaticos.

No ha cribado para quedarse con los mejores, sino que ha cribado para quedarse con los que han tenido que hacerse expertos en entrevistas, que es razonable pensar que no son los mejores sino todo lo contrario.

Esto ya pasa como digo en el punto 2 y con cosas mucho peores.

salvo que sea el trabajo de mi vida, me piden que haga ejercicios de este tipo y no me apetece

Si no te gusta programar piensa que tambien te sirve a ti para decidir la empresa. Puedes no ser un culture fit.
Yo por ejemplo me amargo en mi empresa actual por que soy el unico de backend remotamente inquieto en hacer problemas de este tipo y cuando me pongo a hablar de ello me quedo solo. En empresas asi, muchas veces es un pasa tiempo.

Y quiero volver a decir que ojo: no es una panacea, es un tradeoff. Pero quiero que entiendas que para nosotros es INFINITAMENTE mejor (y objetivamente no tendria peros si dieran alternativas para poder probarte como enseñar un porfolio por ejemplo).
#197 "Si no te gusta programar piensa que tambien te sirve a ti para decidir la empresa".

Me gusta programar, no reinventar la rueda. Programé árboles cuando estudié estructuras de datos, sé sus ventajas y desventajas. Sin embargo, ahora me ponen el ejercicio "encode-n-ary-tree-to-binary-tree", que seguro que es sencillo y que cuando estudiaba estructuras de datos lo habria hecho en cinco veces menos tiempo que hoy, y tengo que gastar unos minutos en recordar/googlear la forma de meter datos en un arbol binario y la forma más eficiente de sacarlos de un arbol n-ario. Esos minutos me descartarían porque el tiempo está limitado para descartar a los que han de buscar la información en lugar de tenerla en la cabeza. Realmente tengo que repasarlo porque es una estructura típica de entrevista, cuando casi todos los lenguajes de programación ya implementan todas esas estructuras de datos de una forma más eficiente que cualquiera que alguien que haga ese test pueda plantear, con versiones concurrentes y no concurrentes que conozco y sé cual usar en cada momento? No sería más óptimo tener a alguien que sepa que eso ya está hecho de forma eficiente y que es una pérdida de tiempo rehacerlo solo porque a un PO se le ha metido en la cabeza que ha de hacerse así?

Enseñar un porfolio no les sirve. Estos tests quieren que tú hagas algo pero que ellos no tengan que revisarlo. Si te gusta programar de verdad, te ha de encantar hablar de por qué has tomado una determinada decisión, por qué has hecho algo de una determinada forma... aquí lo único que importa es que lo que has hecho en el tiempo limitado que te han dado pase los tests. Es una web con un campo en blanco, no hay espacio para el estilo, ni los comentarios, ni los javadocs si usas java, ni tus propios tests ni nada. Solo importa que hayas tenido la idea feliz en el tiempo que te han dado, y esa la vas a tener si has hecho varios ejercicios antes. Si has dedicado tu tiempo a hacer algo en tu github, a contribuir a un proyecto de cualquier cosa o a hacer un programa que usan el 90% de los ingenieros de la empresa que te quiere contratar (como el que comenta el del titular) les da absolutamente igual. Y no estamos hablando de Netflix, que siendo referencia de buenas prácticas en cloud, y teniendo proyectos que ahora mismo usamos (o al menos conocemos) todos los que estamos en el sector, pueden permitirse ese tipo de exigencias y saben que muchos programadores pasarán por el aro porque el "premio" es muy apetecible. Estamos hablando de una práctica extendida que pretenden usar empresas de las que nadie ha oido hablar y tienen que andar buscando gente por linkedin porque nadie les envía el currículum y que, en el momento en que les respondes, te dicen que hagas uno de estos antes incluso de preguntarles qué es lo que hacen y lo que ofrecen.
#198 A ver, primero decir que si lees mis posts, veras que no niego esas desventajas, pero son un metodo preferible de filtro masivo para el trabajador frente a otras practicas mucho mas nefastas.

Me gusta programar, no reinventar la rueda
Quizas deberia haber hecho la distincion que para mi programar es resolver abstracciones de problemas. Y por ello me gusta tambien ver como son esas abstracciones por que puede que las use para componer otras soluciones. Tambien me gusta craftear/makear, tambien es una parte de la ingenieria de software (y de la programacion si tenemos en cuenta las ultimas metodologias ya que a dia de hoy es imposible pensar como programar algo sin tener en cuenta todo el sistema en su conjunto (microservicios, devops, testing) pero se aplican aun las mismas bases), mientras que a esta parte lo llaman "coding" normalmente.

Lo digo desde mi experiencia y lo que leo. Pero generalmente todos los que se quejan de esto son mas "makers" que "coders", les encanta enfarragarseen una tecnologia y montar cosas, pero consideran una frikada salirse de patrones tipicos por que "ya esta todo hecho". A mi me pasa totalmente al contrario. No me parece una frikada repensar siempre como puedo reimplementar algo y no es la primera ni la ultima que me he inventado una concrecion de una estructura (siempre con algo de benchmark y sopesando si valia la pena ese concrecion). Mucha gente en esas empresas son asi. No es nada raro. Y, desde mi punto de vista, es lo normal por que viene naturalmente al estar aprendiendo.

Sin embargo, ahora me ponen el ejercicio "encode-n-ary-tree-to-binary-tree", que seguro que es sencillo y que cuando estudiaba estructuras de datos lo habria hecho en cinco veces menos tiempo que hoy, y tengo que gastar unos minutos en recordar/googlear la forma de meter datos en un arbol binario y la forma más eficiente de sacarlos de un arbol n-ario. Esos minutos me descartarían porque el tiempo está limitado para descartar a los que han de buscar la información en lugar de tenerla en la cabeza. Realmente tengo que repasarlo porque es una estructura típica de entrevista, cuando casi todos los lenguajes de programación ya implementan todas esas estructuras de datos de una forma más eficiente que cualquiera que alguien que haga ese test pueda plantear, con versiones concurrentes y no concurrentes que conozco y sé cual usar en cada momento?

No entiendo esto, sobre todo tras lo que has dicho lo de los dos casos.

* Si es un test tipo hackerrank, puedes usar el lenguaje que salga del napo o copiar lo que te salga del napo de stack overflow :-/. Ademas no es raro que en cuanto hagas 2 o 3 tengas un ficherito con todas esas estructuras. Es mas, cualquier sitio de este tipo tienes acceso a stack overflow y cualquier recurso tuyo o github.
* Si es uno en sede, normalmente es de tipo white board. Asi que eso no se aplica.
* Si es uno en sede pero de este tipo, la empresa es una basura y sales ganando lol.

Pero para mi lo mas importante es como dices que "ya sabes que usar de tu lenguaje de programacion". De nuevo, filosofia maker. "Me memorizo cuarenta cosas y las wireo y fuera". 0 coding. Y muchos seniors tienen este problema, por a o por b. Pero es que tienes que entender que eso es un punto de mejora tuyo y que el no tener esa habilidad te esta afectando en tu productividad.

Ademas de mantener que gente de esas empresas, o yo, nos encanta esas cosas que normalmente serian llamadas "frikadas". Pero no lo son.

Enseñar un porfolio no les sirve. Estos tests quieren que tú hagas algo pero que ellos no tengan que revisarlo

Totalmente de acuerdo, pero como comente, las alternativas son peores Y requieren mucha mas preparacion QUE ADEMAS no tiene nada que ver con informatica.

* Aprender a hacer CVs que pasen clasificadores masivos. Tienes que prepararte mirando que busca la empresa, preparar un CV POR EMPRESA, que ademas este estilizado para esa empresa en cuestion. Y encima no es nada objetivo al final. No sirve de nada para un programador esta habilidad.
* Aprender a bordar los screen calls. Lo mismo de arriba pero encima tienes que tener buenas habilidades sociales y bordarlo incluso en un idioma extranjero (me acaba de pasar que ni siquiera me han dado opcion a demostrar mi habilidad en la prueba tecnica por que tengo un acentaco ingles. Te puedo asegurar que si hubiera llegado a la prueba tecnica, este problema no me hubiese pasado luego).
* Networking. Todo lo de arriba pero ademas tienes que ser extrovertido. Al menos las social skills son bastante importantes en un ambiente de trabajo. Pero es lo mas subjetivo.
* Max(F(CV) )-> CV.getAges + CV.getWords + CV.getwhatever que es el colmo de la mierda. No puedes pretender que un tio 20 años calentando una silla tenga la misma prioridad que alguien que lleve 1/2 años pero tenga una actitud brutal. Esto ya es sintoma de empresa de mierda.
* Y CASI TODAS (menos la ultima) SON SUBJETIVAS Y POCO ENTRENABLES en condiciones, marcandote objetivos y tal.

En ese caso, acepto yo y cualquier programador, por muchisimo, las posibles desventajas que tenga este metodo. Entiendo que gente que ya tiene añitos salen perdiendo por que requieren de un esfuerzo extra, pero es que es un esfuerzo irrisorio en muchos casos.

Si te gusta programar de verdad, te ha de encantar hablar de por qué has tomado una determinada decisión, por qué has hecho algo de una determinada forma...
No puedes hablar con 500 personas, asi que vuelvo a lo de antes. Mejor esto que muchas otras.

Es una web con un campo en blanco, no hay espacio para el estilo, ni los comentarios, ni los javadocs si usas java, ni tus propios tests ni nada.
Clean Code? :-/ Esas practicas estan anticuadas.

Si has dedicado tu tiempo a hacer algo en tu github, a contribuir a un proyecto de cualquier cosa o a hacer un programa que usan el 90% de los ingenieros de la empresa que te quiere contratar (como el que comenta el del titular) les da absolutamente igual.
Deberia serte facil hacer esos problemas si cumples cualquiera de estas condiciones. Y vuelvo al punto anterior que es mejor este filtro que los otros que habia.

Estamos hablando de una práctica extendida que pretenden usar empresas de las que nadie ha oido hablar y tienen que andar buscando gente por linkedin porque nadie les envía el currículum y que, en el momento en que les respondes, te dicen que hagas uno de estos antes incluso de preguntarles qué es lo que hacen y lo que ofrecen.
Esto no es culpa de las empresas si no de tu no filtrar que empresas te cunde entrar a su proceso. ¿Si no te interesa no entiendo por que las empresas deberian gastar tiempo en ti? ¿O por que querrias entrar a esas empresas?

Sinceramente, veo mucho lloro en tu post de lo mamado, cunado prepararse esas pruebas es sencillo y ayuda un monton a tu trabajo diario.
#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.
#199 La prueba técnica de la mayor parte de los equipos de Google ya hace mucho tiempo que no es automatizada. Desconozco si hay algún equipo que todavía la usa porque al final cada equipo tiene cierta libertad para definir su formato de entrevistas.

La eficiencia algorítmica sigue siendo importante, pero ya hace mucho que se dieron cuenta de que esa criba era contraproducente. En la experiencia de la última vez que estuve en procesos de entrevistas, los programas automatizados solo son usados por empresas mediocres que no tienen recursos suficientes como para hacer una buena selección con intervención humana.
#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.
#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.

menéame