Este artículo hace parte de la serie "Entrevistas de Ingeniería Silicon Valley".
Durante una entrevista técnica no se espera que el candidato entienda en su totalidad el problema o la solución óptima desde el primer momento, por lo cual se espera que el candidato haga preguntas aclaratorias y comparta con el entrevistador su punto de vista, confirmando que lo entiende adecuadamente y que está considerando soluciones válidas bajo las restricciones impuestas en el problema.
Al enfrentar un proceso de entrevistas técnicas para posiciones de Ingeniería, se recomienda:
Presentar la hoja de vida con información actualizada y verídica
Es importante asegurarse que la hoja de vida contiene información verídica porque usualmente se hacen preguntas abiertas relacionadas con la experiencia técnica allí mencionada, especialmente la relacionada con proyectos y experiencia aplicada. Al entrevistador le podría dar una muy mala señal aquellos candidatos que exageran su experiencia técnica o se dan créditos por trabajo que no realizaron.
Entender claramente el problema y los supuestos
Asegúrate de entender muy bien la naturaleza del problema, el contexto en el cual existe el problema y las restricciones que puedan definir el nivel de complejidad y viabilidad de una solución. Valida tus supuestos y escríbelos de forma que sean fácilmente referenciables para la toma de decisiones de diseño de tu algoritmo.
Proponer múltiples soluciones, incluyendo las de "fuerza bruta"
En ocasiones no hay una respuesta única u óptima a un problema, por lo cual es buena idea proponer varias soluciones (incluyendo la sub-óptima, conocida como "de fuerza-bruta"), confrontando su complejidad y desempeño teniendo en cuenta el impacto en procesamiento y almacenamiento. Esto le permite al entrevistador saber con certeza que el candidato entiende el problema y las restricciones bajo las cuales debe operar la solución o de entender con mayor claridad qué tipo de tips le pueden ayudar al candidato.
Es muy importante por tanto estar hablando con el entrevistador para hacerle saber cómo estás analizando el problema y qué tipo de análisis estás realizando, es decir, literalmente "pensar en voz alta" evitando silencios incómodos que distraigan y confundan al entrevistador.
Validar la solución a implementar con el entrevistador
Una vez hayas planteado una solución, asegúrate de validarla con el entrevistador y confirmar que estás incluyendo las recomendaciones propuestas. En muchas ocasiones el entrevistador quiere ver como enfrentas la ambigüedad, como incorporas opiniones de otros miembros del equipo para optimizar la solución, por lo cual es importante tener una comunicación clara y permanente antes de proceder a actividades de impementación.
Implementar la solución
Hazlo en el lenguaje con el que te sientas más cómodo, idealmente alguno de los populares actualmente en la industria: bajo nivel (C/C++), orientado a objetos fuertemente tipados (Java/C#) o scripting (Python/Ruby/PHP/Perl), pero definitivamente no en seudocódigo. Aunque no es necesario escribir código que compile, se asume que estás familiarizado con la sintaxis básica del lenguaje (arquitectura general, API -nombres de paquetes, clases, métodos, etc.-).
Hacerle seguimiento al tiempo
Cada entrevista dura 45 minutos pero eso no quiere decir que cada problema deba tomarse esa cantidad de tiempo. Es muy importante por tanto hacer seguimiento del tiempo para asegurarse que estás realizando avances importantes conforme pasa el tiempo. Nuevamente, es importante ir validando supuestos con el entrevistador, de forma que no tomes caminos alternos que puedan hacerte perder tiempo valioso. Tradicionalmente, un problema complejo debe ser resuelto en máximo 35 minutos pero debes tener en cuenta que algunos problemas están concebidos para romper el hielo y deben resolverse en máximo 15 minutos.
Validar que funcione y limpiar el código
Al codificar una solución, asegúrate de que no hay errores o "bugs" haciendo unas pruebas básicas y déjale saber al entrevistador qué tipo de pruebas detalladas, e.g. unitarias, harías para asegurar una mayor cobertura de calidad. De igual forma, no es mala idea si el tiempo lo permite, proponer qué tipo de refactoring podría permitir que el código sea mas legible, limpio y resusable.