#CodeChallenge Mi segundo test, ¿qué errores no debes cometer?.

En este post te voy a contar mi experiencia sobre los errores que tuve resolviendo un code challenge y como puedes no cometer mis errores.

Acabo de terminar un segundo challenge de una empresa. Estaba compuesto de tres pruebas en la plataforma HackerRank. Te comparto mi experiencia y los errores que cometí.

La elección del lenguaje.

Soy programador C#, principalmente. Este lenguaje es una mala elección, me sigue dando problemas y retrasando. No todas las plataformas de coding challenges te van a ofrecer las últimas versiones de C#. En este caso concreto perdí valioso tiempo tratando de usar local functions y pattern matching. La plataforma no los soporta y tuve errores de compilación.  Estoy aprendiendo Scala, este lenguaje es más rápido para escribir, no tiene tantas versiones, lo que reduce la posibilidad de escribir algo que no esté soportado. No me anime a emplear Scala porque no lo domino al cien, pensando en retrospectiva pude ahorrar más tiempo si hubiera elegido Scala.

La cantidad de ejercicios.

Siempre que te ponen más de un ejercicio para resolver te vas a encontrar con un problema. Puedes leer los problemas, y elegir el más fácil al principio, o puedes tomar los ejercicios en la secuencia original. En ambos casos vas a tener riesgos. Si decides leer los ejercicios y luego empezar, entonces, contaras con menos tiempo para resolver los problemas. En cambio, si decides no leer cada prueba, corres con el riesgo de empezar con el más complejo.

En el caso de esta prueba no leí los ejercicios antes de empezar. Seguí la secuencia sugerida. Solo logré completar dos de tres. El tiempo que se me dio fue corto, 60 minutos.

No todos los ejercicios son tan complejos como aparentan.

El segundo ejercicio mencionaba algo acerca de «the closest number». Perdí como 10 minutos tratando de entender que significaba esto. Al parecer, no había un concepto matemático, aritmético o de lógica. El problema consistía en un simple bloque switch. Al menos, las pruebas pasaron con esa solución. Esto me hace pensar que puede haber ejercicios simples, que buscan confundirte.Por lo general, esperas que este tipo de pruebas tengan respuestas complejas, no siempre es el caso.

Empece con Big(0).

En el primer ejercicio, decidí escribir código descriptivo. Esto con el fin de entender bien el problema. Mi primera solución resolvió el problema de una manera ineficiente. La plataforma no me dejaba validar todos los test cases debido a que el algoritmo  tardaba demasiado. En una segunda iteración pude convertir ese Big(0) en un algoritmo más eficiente. En retrospectiva, escribí código de más. Lo que me costó tiempo valioso, no me arrepiento de esto. Prefiero entender el problema a escribir código que no entienda que falle con los edge cases.

Conclusiones.

Estos ejercicios no son reales. La experiencia que tienes como programador puede no servirte. La única alternativa que tenemos para pasar estas pruebas es justo, practicar los code challenges.

 

 

Gustavo Sánchez

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.

Site Footer