Otro al que han peinado del proceso en el que estaba más interesado 
Primera entrevista bastante Gucci; entrevistador sudafricano pero con una pronunciación muy clara. Como dato, al de 5 minutos en la entrevista me dijo que independientemente del resultado de la misma, que mi inglés estaba "on point" y que no me preocupara por eso, lo cual me dio una confianza brutal de cara a futuro (antes siempre daba la excusita de que no tengo titulación oficial pero blabla, ahora es un sí rotundo a la pregunta).
Segunda entrevista igual, buenas impresiones; 1 hora de charla con el que iba a ser (y no fue) mi team lead y otro senior team lead de otro equipo. Fue una sensación extraña hablar en inglés siendo los 3 españoles (el puesto era para la delegación IT española que curiosamente daba soporte a USA). Durante la entrevista entendí por qué me dijo que no me preocupara por mi inglés el tipo anterior. Básicamente fue darles la turra sobre mi experiencia, tecnologías, mi visión sobre algunas cosas en particular, qué había hecho exactamente en algunas partes de trabajos anteriores que mencioné y a grosso modo, nada complejo. Al final de la misma, una pregunta técnica: cómo resolver una relación NxM entre dos tablas y hacer una query que contemple dicha relación con filtrado en base a un nombre. Vamos, 2 joins y un where, easy. Se lo dije oralmente y me dijeron que no hacía falta ni que lo escribiera.
Tercera entrevista, no tan Gucci; viendo cómo se habían desarrollado las anteriores me esperaba un Fibonacci o algo del palo y qué va, la tipa de HR de avisó que reservara 4 horazas para el challenge. Me dieron acceso a un repo privado para hacerle fork y cuando tuviera la solución, hacerles la PR pertinente. El repo tenía un servidor picado en Python con threads, mutex, y moviditas chachis por doquier que tenía que consumir mi solución. Trago saliva y me pongo a leer el README. Lo primero en lo que hacen hincapié es que en sistemas Linux y Unix correría perfectamente pero que no podrían asegurar que en Windows fuera la misma experiencia. Primera paranoia: "¿Me estarán insinuando que use Docker?" A ver, he usado Docker, pero como todo hijo de vecino que lleva en el sector lo justo para no cagarse encima, si tengo que levantar un Docker lo hago leyendo y contrastando a cada paso que doy y eso me comería mucho tiempo (no había aún empezado con el ejercicio). Total, me pongo a hiperventilar mientras voy mirando enlaces que tenía de veces anteriores que me puse a mirar Docker y al final digo, mira, lo lanzo y a tomar por culo. Pues sí, funcionó perfecto. Media horita a la verga por un enunciado y mi paranoia 
sigo con el ejercicio y narra lo siguiente: Se iban a generar 1000 records aleatoriamente cada vez que se lanzase el servidor, los cuales iban a ser suministrados a través de 2 endpoints. Uno exponía json y el otro exponía xml (detalle importante, por suerte o por desgracia, nunca había trabajado consumiendo xml SOAP). En un tercer endpoint que aceptaba json, tenía que ir enviando las coincidencias. Los records podían estar entre los records suministrados por ambos endpoints, sólo en uno de ellos, o podrían estar malformed y por ende, ser descartados en el propio request o parsing. Además, los 3 endpoints tenían una peculiaridad y es que estaban relacionados. Es decir, podría darse el caso de que en base a X criterio, en un momento dado uno de los endpoints retornase un 406, indicativo de que había que pasar a consumir el otro endpoint o que no se habían enviado los records necesarios hasta ese momento (asumiendo que debían estar ya emparejados) y por ello que el endpoint a consumir fuese el post. Lo que había que enviarle al post eran los records categorizados por joined u orphaned, asumiendo que los malformed los descartaría el propio proceso. A esto había que meterle tests, comentarios describiendo el código, posibles mejoras si fuera oportuno, y asumir que en la review le iban a meter un batch mayor de 5000 registros. También hacían bastante hincapié en el rendimiento de la app. Esto que estoy explicando obviamente lo hago a posteriori, durante la lectura del ejercicio en vivo me enteré -1 por la ambigüedad de algunos enunciados y el estrés. A toro pasado, con la cabeza más fría, se me ocurrieron varias formas de abordarlo bastante más óptimas que lo que hice (diccionario donde los orphaned serían básicamente las keys existentes que no se hubieran borrado al encontrar la coincidente, promesas en tasks independientes por petición que el uso del diccionario posibilitaría sin importar el orden, el polling y el cacheado del que no me aproveché por ser zote y usar un scaffolding de aplicación de consola sin IHttpClientFactory (sí era en .NET) con el cacheado y el polling que mete por defecto y usar el HttpClient sin opciones por desconocimiento, etc.). Lo del polling lo leí a raíz de que el feedback que recibí, entre otras cosas, fue que la app era lenta de cojones. En fin, que me metieron un buen palo por el ojete. Ah, si no estuve otros 30 min o más con lo del SOAP no estuve nada, que además había que anidar los records.
¿Cómo de razonable veis esa prueba en 4 horas para 2 años de exp?
sigo con el ejercicio y narra lo siguiente: Se iban a generar 1000 records aleatoriamente cada vez que se lanzase el servidor, los cuales iban a ser suministrados a través de 2 endpoints. Uno exponía json y el otro exponía xml (detalle importante, por suerte o por desgracia, nunca había trabajado consumiendo xml SOAP). En un tercer endpoint que aceptaba json, tenía que ir enviando las coincidencias. Los records podían estar entre los records suministrados por ambos endpoints, sólo en uno de ellos, o podrían estar malformed y por ende, ser descartados en el propio request o parsing. Además, los 3 endpoints tenían una peculiaridad y es que estaban relacionados. Es decir, podría darse el caso de que en base a X criterio, en un momento dado uno de los endpoints retornase un 406, indicativo de que había que pasar a consumir el otro endpoint o que no se habían enviado los records necesarios hasta ese momento (asumiendo que debían estar ya emparejados) y por ello que el endpoint a consumir fuese el post. Lo que había que enviarle al post eran los records categorizados por joined u orphaned, asumiendo que los malformed los descartaría el propio proceso. A esto había que meterle tests, comentarios describiendo el código, posibles mejoras si fuera oportuno, y asumir que en la review le iban a meter un batch mayor de 5000 registros. También hacían bastante hincapié en el rendimiento de la app. Esto que estoy explicando obviamente lo hago a posteriori, durante la lectura del ejercicio en vivo me enteré -1 por la ambigüedad de algunos enunciados y el estrés. A toro pasado, con la cabeza más fría, se me ocurrieron varias formas de abordarlo bastante más óptimas que lo que hice (diccionario donde los orphaned serían básicamente las keys existentes que no se hubieran borrado al encontrar la coincidente, promesas en tasks independientes por petición que el uso del diccionario posibilitaría sin importar el orden, el polling y el cacheado del que no me aproveché por ser zote y usar un scaffolding de aplicación de consola sin IHttpClientFactory (sí era en .NET) con el cacheado y el polling que mete por defecto y usar el HttpClient sin opciones por desconocimiento, etc.). Lo del polling lo leí a raíz de que el feedback que recibí, entre otras cosas, fue que la app era lenta de cojones. En fin, que me metieron un buen palo por el ojete. Ah, si no estuve otros 30 min o más con lo del SOAP no estuve nada, que además había que anidar los records.
