que es una entrevista técnica - parte 2

#12 en la universidad te lo enseñan y se dan varias asignaturas.

hoy en dia trabajar en equipo es igual de importante que saber programar.

#11 Pues hombre, te faltan herramientas elementales.

Aprende sobre Maven y Gradle, como se usan para hacer build, gestionar dependencias, correr tests... Es básico. Lo importante es gestionar dependencias, build, test y run de tu codigo. No hay mas misterio ni hace falta mas para la gran mayoria de codigo.

Y lo mismo lo encontrarias en otros ecosistemas, en algunos forma parte del tooling oficial como Go o Rust, en otros como Python o Javascript/Node, tendrías alternativas como Poetry y Conda para python. Npm, Yarn, Deno para javascript por ejemplo.

Aprender a usarlo... como digo, no hace falta un gran nivel tecnico de entendimiento sino nivel de usuario. Pues son un par de dias de toquetear... No mucho mas.

CI/CD pues para correr procesos que todo el equipo necesite, como los tests y desplegar el código de manera automática.
https://github.com/features/actions
https://docs.gitlab.com/ee/ci/

Aprender a poner las 3-4 pipelines/workflows básicos de nuevo, son un par de dias de toquetear. No tiene mucho misterio. Si sabes lo que es un script... pues lo estas corriendo en una maquina virtual... no tiene ningún secreto.

Como empiezas? Pues empieza añadiendo maven o gradle a tu proyecto java para gestionar las dependencias, hacer el build y test.
Y una vez tienes un entorno funcional prueba a subirlo a Github y Gitlab y ejecutar tu build y test en estas paginas.

Iba a hacer un hilo pero bueno, siguiendo el feedback que me han dado aprovechare este hilo.

He entregado una prueba.

Paso 1: funciona?

Primero un README con explicación:

En el README esta bien comentar lo que has hecho y lo que no, en este pongo unas referencias de papers que he usado o para comentar en el futuro. Comento lo que he implementado y lo que no porque me daba pereza... En este caso por ejemplo mi api no devuelve 400, 404 ni demas validaciones... devuelve todo 500 y a pastar. Tampoco tengo HTTPS (no lo pedia). Me he centrado en resolver lo que me han pedido. Tambien me dedican que los objetId debían ser de una manera concreta, NO LO HE VALIDADO TAMPOCO, que mas da? No veo en que ese detalle influya en la prueba, creo que esta relacionado con el algoritmo de "partitioning" que he usado o era una pista sobre ello.

La estructura del codigo un poquito ordenada y siguiendo el estándar habitual:

Tres GitHub Actions / workflows, muy simples, para test, Lint y los de integracion:

Todas pasan, no soy Codely o Miudev.

Ahora, si tu eres el entrevistador pues te haces un clone mismo y miras si de verdad esas Action funcionan. Yo antes de entregar le he hecho re-run a todo.

Asi que PASO 1 completado. MI codigo funciona.

Paso 2: Resuelve el ejercicio?

Ahora mi codigo resuelve el ejercicio? Para ello hay que mirar los tests. Y ya os he comentado que he tomado las libertades que he creido.

Mi test de integracion es muy simple, casi todos mis tests los ha generado ChatGPT... Y no tengo problema en comentarlo en la entrevista y decirlo. Fijaros que lo que estoy testeando es que subo un archivo y me lo descargo. Para esta prueba, este mini test pues ya esta bien, podria hacerlo mas complejo y hacer multiples PUT? podria, pero chatgpt no me lo ha hecho, y la verdad, me da pereza. No creo que sea muy relevante. Lo que importa es que el test de integración existe y se corre en CI.

Los test unitarios son mas completos, y utilizo unos mock para comprobar que el codigo ejecuta el path que quiero. Son muy simples, si quiera hacer test de integracion debería meter test containers por ejemplo. No me apetece.

Asi que paso 2, resuelve lo que tiene que resolver? Si.

Conclusiones Paso 1 y Paso 2

Como podeis intuir por lo que os comento, porque no puedo compartir el código y solo enseñare lo minimo. Mi codigo no es nada del otro mundo hasta aqui. Es codigo simple, no es el mas eficiente ni óptimo, los status code y cosas de HTTP me los he fumado.

Entonces, porque he completado el paso 1 y paso 2? Porque he escrito buenos tests tanto de integracion como unitarios, que demuestran, que he resuelto la prueba. La prueba me pedia 2 cosas solo, bajo un par de restricciones. Pero la prueba consistía en hacer UN PUT y UN GET y que funcionase. Y eso esta resuelto, y de manera fácil y rápida, lo puede comprobar el evaluador.

De hecho he escrito tan poco codigo que hasta hay alguna cosa como el objectId que he comentado que me lo he fumado. Porque se al 100% que solo era una pista para la gente con menos experiencia. Asi que, he entregado una prueba, relajado de que esta correcto, usando ChatGPT para los tests, y dejándome cosas. Si. Y estoy convencido de que voy a pasar este proceso sin problema y os lo comparto. Para que veáis lo que realmente importa y lo que no.

Paso 3: Mi solución en si

Llegados a este punto yo estoy muy convencido que estoy fuerte. Pero el entrevistador tambien tiene que pensar: este tio pilota. En lugar de: este tio no se ha leído ni el enunciado. Es un riesgo que no me importa tomar.

Para empezar he utilizado todo tecnología e ideas de implementación que estan en State Of Art del problema. Lo he puesto en el README. Y he referenciado las posibles preguntas que me harán en el futuro, para dejar claro que no hay detalle que no pueda implementar en la siguiente entrevista si quieren.

Segundo en mi código he utilizado: métricas y logs, he utilizado circuit breakers para llamas externas, he utilizado un par de técnicas avanzadas de sistemas distribuidos como virtual nodos, el hash que he utilizado también es un poco especial por ser super eficiente. Así que si, he programado 200 lineas quizás 300 lineas de código. Y en estas me he centrado en dejar de talles de "calidad" que cualquier otro ingeniero vera que se lo que estoy haciendo.

Veamos unos ejemplos:

• Circuit breaker por METODO y NODO. Con métricas y logs especificos. Esto lo que implica es tener control absoluto en todas las peticiones al servicio externo que uso. Si por ejemplo tenemos dos regiones EU y US, y peta 1 región, no afectara a todo mi servicio. Si solo peta una AZ, tampoco afectara a toda la región. Ademas, puedo tener el CB a nivel de tenanat/usuario... Cuando el circuito cambia de estado como digo logeo y meto métricas. En fin, esta perfecto, porque de hecho yo he colaborado en esto en el ecosistema Go... Asi que estoy tranquilo en este sentido jaja.
• Os voy a enseñar un turquino de parsing y una MALA PRACTICA típica de Tiktoker. Pero ahi va. Usar SPLITS es una MALA PRACTICA. String.Split() es una mala practica!!!! Siiiii. tiene sus casos de uso, no soy un tiktoker, pero la mayoria de gente lo usa mal. Aqui teneis un detallito de calidad:
  

El punto clave es que un split devuelve un silce, array, vector. Y en una variable de entorno "VAR_A=" es un input valido, de hecho podríamos tener mediante chars especiales (si no me equivoco), "VAR_A=fo=bo" o similares... Si hacemos un split en el = tendremos que comprovar el tamaño del array y luego el contenido... En conclusión, como se Rust y cosas de bajo nivel, y se que se hace con estos métodos pues lo he hecho bien.

Y aqui he sido un poco cabroncete. Me he ido al GitHub publico de la empresa donde estoy aplicando y he buscado casos de uso donde hagan split... Y he visto 2 o 3 sitios como este donde ese codigo esta mal. Asi que en la entrevista. Se lo voy a enseñar.

• Algo básico, todo el tema de I/O es async obviamente. Cuando subo un fichero a un nodo lo hago en stream/multipart y dejo que la stdlib y el kernel se encarguen de la transmisión y los retries... De nuevo, en esto he trabajado al mas alto nivel y en librerías open source como Reactor, Betty y similares. Tengo los huevos pelados que dicen.

Aqui tambien he sido perro y he mirado otras soluciones de otra gente que estan por GitHub, no lo hacen en streaming todo... hay cosas que leen en memoria. Es decir copias y luego vuelves a copiar al buffer... Puede tener out of Memory, te puede petar una transmisión, ademas que delegas el retry al user space en lugar del kernel... Una puta porqueria vamos.

• Otro ejemplo que parece tonto si no sabes lo que estas viendo, pero es la diferencia es este filtrado. Mucha gente hace un List() y luego filtra en su proceso. Eso esta mal. Yo aqui que estaba usando el SDK de Docker para pillar unos cointainers según la network, le he pasado un filtro:
  

Como sabia que esto se puede hacer? Pues he buscado en Github en todos los repositorios del mundo esta string: "containertypes.ListOptions{" y me salían todos los ejemplos de proyectos públicos que hacen este listado.

Sorpresa, NO HAY NADIE EN EL MUNDO, que haga el filtro bien de docker.. al menos en codigo open source. Soy el unico. Pues esto se comenta en la entrevista obviamente. Y de nuevo, los otros entrevistados tambien hicieron mal...

Quizás este List es una tontería, pero lo que esta linea de codigo esta comunicando es que entiendo lo que estoy haciendo y estoy usando el mejor codigo eficiente y optimo para cada situación. Es el equivalente a hacer una query bien optimizada a db vs hacerlo tu en runtime al recibir una respuesta peor... todo suma.

• luego tema http, no le he metido status code y tal ya lo he dicho. pero si he metido logs y métricas inFlight del numero de peticiones que recebimos. si estoy escribiendo una gateway es importante estas métricas. al final esto es un tema de conversación y es un must en cualquier codigo para producción... de nuevo, soy el unico candidato de todos los que he visto en github ( otros 3 programadores) que ha puesto métricas y logs de calidad.

Conclusion

Bueno como veis en el tocho post, he hecho lo que de verdad importa. Mirando las otras soluciones, si 4 o 5 candidatos han hecho el mismo problema que yo. Todos podemos resolverlo. Pero yo he sido el unico con tests, con tests de integración, con CI en Github, con explicación en el README, con los detalles que comento arriba de circuit breaker, técnicas avanzadas de sistemas distribuidos, métricas, logs... etc. Lo que me he centrado es en resolver el problema, que funcione bien, rápido, eficiente y bastante cerca de ser la solución mas optima de hecho. Y sobretodo, he escrito codigo para el mundo real.

Y como veis no me he esforzado nada en las bobadas que alguien como Codely os venderían. Arquitectura hexagonal? No aporta nada. Hacer DDD o streming de eventos? Complica el codigo... Tu servicio sera mas lento, consumira mas RAM y CPU, tendrá mas puntos de fallo... sera una mierda vamos. Ah, y los tests, con ChatGPT y a otra cosa.

No se, aqui todo el mundo es libre de opinar lo que crea. Vosotros creéis, que yo, por no haber hecho los status code perfectos, no haber validado eso del objectId y dos o tres pijadas mas no debería pasar la prueba? Crees que hacer estas cosas importan para algo para un ingeniero? Ya os digo yo que no. Y si importan y no paso la prueba, viendo el nivel del equipo, tampoco pasa nada.

Cualquier programador te sabe tocar los status code de una respuesta, mappear el error, meter HTTPs... Esto no demuestra nada. Hacer que todo tu servicio funcione completamente en streaming/async y en lugar de consumir 2Gib de memoria y procesar 5k req/s, lo haga en 20MiB y haga 15k req/s. Si importa. De hecho si quiera asegurarme pasar esta prueba al 100%, le habria metido un benchmark y a tomar por culo, os lo recomiendo. Pero no quería complicarme ni dedicar mas tiempo.

Comentadme si quereis screenshots de algo del codigo si no queda claro.

Aqui teneis el ejemplo: https://github.com/vrnvu/java-todo-list

He tardado 1 hora y poco en hacerlo. Creo que el nivel es casi junior. Faltaria algunos detalles pero esta casi terminado. Y yo diría que es casi junior. No creo que hace falta hacer mucho mas, todo lo extra que le metas te va a sumar puntos. Pero es importante que no se te vaya la cabeza metiendo sobre-inginieria que no aporta valor.

Por ejemplo es importante mirar el test coverage:



Lo importante no es tener el 100%, sino que lo importante es que si en algun caso tiras un error, tengas eso en cuenta y lo testéis.

Teneis la pipeline para correr los tests: https://github.com/vrnvu/java-todo-list/blob/main/.github/workflows/build-and-test.yml
Para los que decis que no os enseñan.

Ademas yo uso nix/flox, asi que si teneis flox, os instalara la SDK de java que uso y el gradle exacto para que en local os vaya perfecto.

Podéis usar mi template como base para los que queríais practicar.

Cosas que podríais añadir, algunas mas difíciles que otras:

• ahora mismo el codigo tiene condiciones de carrera, usar ConcurrentHashMap y testearlo (dificultad facil)
• cambiar mi inMemory por una H2, ya teneis la dependencia puesta (dificultad fácil)
• una DB como postgres, RDS, dynamo, mongodb etc... para ello necesitareis tambien docker y docker-compose para tener tests de integracion. (dificultad media)
• micrometer y log4j y configurarlo (dificultad facil)
• añadir un prometheus + grafana + opentelemetry para ver los métricas y logs (dificultad medio-difícil)
• tener mas clases para separar dominio, DTOs, y etnitites. Validaciones y parseos tambien (dificultad fácil)
• desplegar tu servicio a un AWS/AZURE/GPC (dificultad media)
• tener gestión de excepciones y mappear las excepciones de tu servicio, repositorios en el controller a errores HTTP (dificultad fácil)
• tener entornos de spring de dev/pre/pro para configurar la aplicación (dificultad fácil)
• auth, usuarios, sesiones, jwt, OAuth2 (dificultad media, dificil)
• ahora mismo no uso tomcat, le he metido netty directamente, que ya es un +1, pero el codigo no es full reactivo xq necesitaría reactor y usar SDK async... hacer tu servicio full async (dificultad muy difícil)

Hablando desde el punto de vista técnico, creo que esto serian las cosas principales.

Para casos de uso de negocio puse atrás ideas.

Espero que os sirva.

Segun ChatGPT:

Interpretación de la Línea de Habilidades

• JUNIOR: Manejas tareas básicas de concurrencia y persistencia en memoria.

  • Ejemplos: ConcurrentHashMap, H2 en memoria.

• Intermedio: Puedes manejar bases de datos externas y configurar monitoreo básico.

  • Ejemplos: Docker, Docker-compose, Postgres, Micrometer, Log4j.

• Avanzado: Configuras y despliegas entornos completos con monitoreo avanzado y separación de responsabilidades.

  • Ejemplos: Prometheus, Grafana, OpenTelemetry, despliegue en AWS/AZURE/GPC, gestión de excepciones, entornos de Spring.

• Semi-Profesional: Implementas autenticación avanzada y gestionas servicios en la nube de manera eficiente.

  • Ejemplos: JWT, OAuth2, despliegues en plataformas cloud.

• PROFESIONAL: Desarrollas servicios completamente reactivos y asincrónicos utilizando tecnologías avanzadas.

  • Ejemplos: Netty, SDK async, full reactive programming.

Plan de Mejora Continua

1. Condiciones de Carrera y ConcurrentHashMap: Prioriza resolver condiciones de carrera y utilizar ConcurrentHashMap para mejorar la concurrencia y estabilidad del sistema.
2. Migración a H2: Sustituye el almacenamiento en memoria por una base de datos H2 para mejorar la persistencia.
3. DB Externa y Docker: Introduce una base de datos como Postgres y configura Docker para pruebas de integración, fortaleciendo la infraestructura de la aplicación.
4. Monitoreo y Logging: Implementa Micrometer y Log4j para el monitoreo básico, luego expande con Prometheus y Grafana.
5. Separación de Clases y Validaciones: Organiza mejor el código separando el dominio, DTOs y entidades, y agrega validaciones y parseos.
6. Despliegue en la Nube: Configura despliegues en AWS, Azure o GPC para entornos de producción.
7. Gestión de Excepciones: Mejora la gestión de errores y asegúrate de mapear excepciones a códigos HTTP adecuados.
8. Entornos de Spring: Configura múltiples entornos de Spring para facilitar el desarrollo, pruebas y despliegue.
9. Autenticación y Seguridad: Implementa autenticación robusta con JWT y OAuth2 para asegurar la aplicación.
10. Servicio Reactivo: Finalmente, transforma el servicio a una arquitectura completamente reactiva utilizando Netty y programación asincrónica avanzada.

See also

• JWT Authentication
• Docker Compose for Postgres
• Prometheus and Grafana Setup

You may also enjoy

• Deploying to AWS
• Building Reactive Applications

#26 Te estás respondiendo a tu pregunta. No consumas información inútil ni hagas cosas inútiles. Cuando encuentres información útil, presta atención. Transforma la información en resultados. Cuanto más crees, mejor.

La ingeniería es un arte creativo más. Crees que si pintas cada día el mismo retrato, sin cambiar nada, vas a progresar? Qué crees que va a pasar si estudias teoría del color, formas y volúmenes, iluminación, y luego experimentas con distintas técnicas? La maestría en una disciplina no se obtiene de hacer siempre lo mismo de la misma manera durante 20 años.

Eres un pintor y has pasado 20 años pintando a tu mujer, que posa para ti todas las mañanas. Un día decides ir a la plaza del pueblo a pintar a más gente para ganar un dinerillo extra. Un niño y su padre se acercan y te piden un retrato sonriente. Aceptas sin dudar. Al mirar al niño, notas que no tiene el pelo largo ni rubio como tu mujer, ni la misma forma de cara, ni la misma ropa.

Los únicos programadores que te van a decir que llevan 20 años haciendo lo mismo, de la misma manera, entre excusas de que se van actualizando y que han evolucionado y son muy buenos, son los programadores que no saben pintar.

Nadie puede decirte qué camino tomar porque solo tú sabes dónde estás, de dónde vienes y adónde quieres ir. Desconfía de cualquiera que te dé pasos a seguir. La verdad es más simple: si caminas en una buena dirección, llegarás a un buen lugar. No te preocupes tanto por el destino exacto.