A este artículo lo pueden encontrar útil quienes programan en Java, quienes todavía no consiguieron su primer trabajo como programador, o quienes alguna vez deban presentar un coding excercise como demostración de sus habilidades. La historia comienza así: me rebotaron de Cabify. Mi coding exercise no les gustó. Al principio, no sentí alegría. Antes además, también me habían rebotado de un puesto en la alegre ciudad de Lisboa.

Dada la alta demanda del mercado, es tentador arribar a la conclusión que uno es un programador mega creativo, entendedor y capaz de confeccionar soluciones magistrales. Que las recruiters anhelan ubicarte en sus búsquedas, y que los equipos de desarrollo quieren tenerte de compañero.

En realidad, se puede pensar bien de las habilidades propias, pero hay que cuidarse de no interpretar la alta demanda como estrellato. Después de todo, somos como enanos sobre los hombros de gigantes.

A partir de estos rebotes, aprendí dos cosas (y quizás tres) que pueden afligir a un programador durante una búsqueda laboral… independientemente del seniority. La primera es especialmente cierta cuando uno no manipula cierta tecnología hace tiempo. Si ese es nuestro caso, durante la entrevista, cuando nos pregunten cómo resolveríamos algo, puede que nos olvidemos ciertas palabras técnicas y terminemos explicando que conectaríamos el coso con el coso.

El entrevistador notará que uno sabe (conectar cosos) pero no sin alertar al sentimiento precautorio que vigila la interacción en búsqueda de posibles riesgos ocultos. Pero una cosa más. Cuidado, también. Porque si además de conectar cosos, elegís compartir tu opinión sobre la dosis de entretenimiento que te genera programar aplicaciones CRUD, siendo extremadamente explícito, diciendo que son aburridas… bueno. Te tengo obvias noticias.

El otro riesgo es más amenazante y entra en el reino de lo incierto no-obvio. Me refiero al coding exercise. Desconocer los criterios de aprobación y de rechazo puede dejarte con la ilusión de haber presentado un ejercicio demostrativo y bien logrado, y sin embargo terminar al horno, adobado con la etiqueta de rejected. Así me pasó esta vez. Y como veremos en unos instantes, esta lección me resultó fundamentalmente dolorosa valiosa. Y la quiero compartir.

Dado que lo importante es identificar nuestros errores cosa de poder transformarlos en areas de mejoría, tras un rechazo sin causa, lo aconsejable es solicitar el feedback de manera amable.

Subí la consigna de Cabify y el código (rechazado) de Java acá. Lo que sigue es el feedback.

---

Solution
– It works but does not full-fills the requirements
– No documentation on decision making, though-process and trade-offs
– The deliverable does not includes documentation on how to run it
– Libraries included are not justified nor documented

Production readiness 
– Deliverable must be modified to be deployed to prod.
– The application does not includes any logs
– No error messages

General code style 
– Code lacks consistency and does not follows Java community standards
– Candidate uses data structure classes directly instead of their interface
– Candidate does not always specify the accessibility of the fields of the classes it uses
+ Naming (classes, methods, modules, variables, parameters) is clear and does reflect business concerns
+ No abbreviations
+ Low cyclomatic complexity
– No comments whatsoever
+ [Bonus] Small functions
+ [Bonus] Small objects or modules
+ [Bonus] Max chars per line

Design 
– Code is not so maintainable and must be modified before allowing extension points
+ Solution is not over-engineered
– Code does not follows always SOLID principles.
–  Code performance has not been analysed and documented
– Internals are exposed to the world in some cases.
– Anaemic domain model
+ Follows the Law of Demeter
+ [Bonus] Functional flavour. Reduced side-effects thanks to immutability and referential transparency

Testability
+ It has tests with clear names and well-written expectations
+ Dependencies with side-effects are replaced with Test Doubles
+ Clearly separted blocks for arrangement, execution and assertion
+ Tests follow FIRST principles

---

Cabify tiene la vara super alta, y está bien si es lo que buscan. Pero también noto su demanda por un elevadísimo número de horas a invertir en un ejercicio antes de tener entrevista alguna. Temo que esto se convierta en una práctica común.

Hacia Un «Coding Exercise» Magistral

Continué mi búsqueda; siendo exquisito: quería trabajar en Portugal, España o remoto. ¿La meta? hacer kitesurf. Debido a que me quedaban pocos ahorros, cedí en mi idea de un puesto desafiante y apliqué para un e-commerce. Hice el ejercicio con Elixir. Esperé. Y continué esperando. Y no pasó nada.

Me rechazaron con la excusa de necesitar a alguien más experimentado, sin darme feedback. Insistí. Y nada.

Pero yo iba trabajar con Elixir. Aunque las empresas pedían tres años de experiencia, yo aplicaba igual:

Tuve una pequeña video llamada. Luego me enviaron un ejercicio. Ahora, si no fuera por el e-commerce, este hubiera sido mi primer coding exercise usando Elixir. Aunque no me dieron ningún feedback, esa experiencia me sirvió para acumular práctica.

LA REVELACIÓN

Los últimos rebotes me dolieron. Esta vez me pidieron que suba el código a Github. Me preguntaba si alguien ya lo había hecho. Encontré dos personas y ninguna trabajaba para la empresa. Entonces agregué a uno en LinkedIn, coméntandole la situación.

Resultó que lo habían rebotado. Él tenía un email con el feedback. Se comportó como colega y me lo pasó. Ahora yo conocía los criterios de rechazo.

Dos días más tarde envié mi código:

Lo había pulido con lija al agua, quería entrar. La recepción fue buena. Tan buena que durante la entrevista decidieron no hacerme preguntas técnicas. Un ruso cráneo top-malabarista de bits que programa ahí, me comentó que ni tuvo necesidad de mirar el código hasta el final, dejando dos archivos sin abrir.

A VECES NO ES UNA TRAGEDIA

Hacer un coding exercise es la práctica de facto. Algunas empresas no te darán feedback y se sentirá un frustrante. No obstante, habrás acumulado horas de experiencia, especialmente valiosas para cuando estás buscando tus primeros trabajos.

Alguna vez leerás a la gente recomendar “programar algo, cualquier cosa y subirlo a github”. Ya sabemos cómo resulta eso: no tenés una consigna y a no ser que tengas un premio placentero en mente, tampoco estarán las ganas. Mi sugerencia es que apliqués demostrando tu predisposición a realizar un coding excercise e ir viendo de innovar con lo que venga.

Si te piden subir tu código a GitHub, podés buscar a ver quien lo hizo antes. Luego a su programador en LinkedIn. Y cuando veas que ingresó, ya contás con un ejercicio de inspiración. Cuando no, recordá que estamos en la misma, nacimos dueños de nuestras reacciones y que, a veces, no es una tragedia.