Abres la invitación a la entrevista y lees algo como: “tendremos una etapa técnica”. Listo. En tres segundos, el cerebro ya abre unas quince pestañas: “¿pedirán algoritmos?”, “¿y si me bloqueo?”, “¿será que para el viernes necesito dominar bases de datos, API, pruebas, arquitectura, Docker, Kubernetes y un montón de cosas que ni siquiera estaban claras en la vacante?”.
Si eres estudiante, junior o estás en transición de carrera, esta inseguridad es bastante común. Muy común.
La buena noticia es que las entrevistas técnicas no tienen por qué convertirse en un teatro de respuestas memorizadas. En muchos procesos, la empresa intenta observar señales de razonamiento, comunicación, fundamentos, experiencia práctica y disposición para aprender. Eso no significa que las entrevistas sean perfectas. Varían mucho entre empresas, pueden tener sesgos y, en ocasiones, miden mal la competencia real de una persona desarrolladora.
Aun así, es posible prepararse mejor. No intentando adivinar todas las preguntas posibles, sino creando recursos para afrontar distintos formatos de conversación técnica.
TL;DR
- Una entrevista técnica no consiste solo en acertar respuestas; también implica mostrar razonamiento, comunicación y claridad.
- Pregunta antes sobre el formato de la etapa: conversación, desafío en vivo, proyecto, arquitectura, fundamentos o una mezcla de todo eso.
- Estudia a partir de la vacante, priorizando lo que aparece como responsabilidad central.
- Durante los desafíos, piensa en voz alta: confirma el problema, pregunta por las restricciones, propone una solución sencilla y valida casos.
- Prepara ejemplos de tus proyectos, aunque sean de cursos, universidad, voluntariado, trabajos freelance o estudio.
- Después de la entrevista, registra lo aprendido sin convertir un rechazo en una sentencia sobre tu capacidad.
Una entrevista técnica no es un examen de respuestas memorizadas
Es tentador pensar que una entrevista técnica es un examen oral con una respuesta secreta guardada en algún lugar misterioso del proceso de selección. Pero, en la práctica, muchos entrevistadores quieren entender algo más sencillo y útil: cómo piensas frente a un problema.
Esto incluye preguntas como:
- ¿puedes explicar una decisión técnica con tus propias palabras?
- ¿sabes reconocer cuándo no sabes algo?
- ¿puedes hacer preguntas antes de empezar a programar?
- ¿entiendes los fundamentos básicos de la tecnología que dices conocer?
- ¿aprendiste algo con proyectos anteriores?
- ¿recibes feedback durante la conversación o ignoras todas las pistas?
Por otro lado, no conviene romantizar el proceso. Las entrevistas técnicas tienen limitaciones. Una persona puede tener un mal desempeño por nerviosismo, por no conocer el formato, debido a un enunciado confuso o a una dinámica poco acogedora. Además, distintas empresas evalúan cosas diferentes. Algunas dan mucho peso a los algoritmos; otras se enfocan en la experiencia de producto; otras combinan conversación técnica, desafío práctico y discusión de proyectos.
Por eso, la preparación no debería consistir en “memorizar respuestas para todas las preguntas posibles”. Una mejor preparación es construir recursos: repasar fundamentos, practicar problemas, explicar decisiones en voz alta, estudiar la vacante y reflexionar sobre experiencias reales.
Aquí existe un trade-off. Estudiar para entrevistas no es exactamente lo mismo que estudiar para el trabajo cotidiano. En el trabajo real, investigas, conversas con colegas, lees código existente, pruebas hipótesis y cambias de opinión. En algunas entrevistas, necesitas resolver algo en un tiempo limitado, mientras alguien observa. Hay una superposición, claro: los fundamentos, la claridad y la práctica ayudan en ambos contextos. Pero algunos formatos de entrevista requieren entrenamiento específico, del mismo modo que entrenar con una pelota no es igual que jugar una final con la hinchada gritando.
Si quieres profundizar en esta visión de la práctica profesional, con atención a la calidad, el aprendizaje continuo y la responsabilidad técnica, también vale la pena leer sobre qué es Software Craftsmanship.
Conoce los formatos más comunes de entrevista técnica
Antes de empezar a estudiar cualquier cosa, intenta descubrir el formato de la etapa. Puedes preguntar de manera sencilla y profesional:
“¿Podrías decirme cómo será la entrevista técnica? ¿Habrá una conversación sobre experiencia, un desafío en vivo, pair programming, un ejercicio en una plataforma o una discusión de arquitectura?”
Esto no es “pedir las respuestas”. Es alinear expectativas. El proceso cambia según la empresa, la seniority, el área, el stack y la vacante. Para una posición junior, puede ser una conversación sobre fundamentos con un ejercicio pequeño. Para una vacante con más experiencia, pueden aparecer diseño de sistemas, arquitectura, toma de decisiones y discusión de trade-offs.
Conversación sobre fundamentos y conceptos
Este formato suele evaluar conocimientos básicos del área y de las tecnologías de la vacante. Pueden aparecer temas como:
- lenguaje principal de la vacante;
- orientación a objetos u otro paradigma relevante;
- API;
- bases de datos;
- pruebas;
- Git;
- HTTP;
- nociones de arquitectura;
- prácticas de desarrollo en equipo.
El punto no es recitar una definición de manual. Si alguien pregunta “¿qué es una prueba automatizada?”, una respuesta memorizada puede incluso comenzar bien, pero se debilita si no conectas el concepto con un uso real.
Una respuesta más interesante sería algo como:
“Una prueba automatizada es código que verifica si otro código se comporta como se espera. En una API, por ejemplo, podría probar si el endpoint de creación de usuarios valida los campos obligatorios. Esto ayuda a evitar que un cambio futuro rompa una regla importante sin que el equipo lo perciba.”
Observa que no es una respuesta teatral. Es una explicación con tus propias palabras, contexto y un ejemplo.
Ejercicios de lógica, código o resolución de problemas
Aquí pueden aparecer ejercicios en un editor compartido, una plataforma online, papel, pizarra o mediante una conversación. El ejercicio puede ser sencillo, como manipular listas, strings y objetos, o más elaborado, según la vacante.
Un error común es empezar a escribir código inmediatamente, como si el teclado fuera un salvavidas. Antes de programar, entiende el problema.
Pregunta cosas como:
- ¿cuáles son las entradas?
- ¿cuál debe ser la salida?
- ¿existen valores inválidos?
- ¿la lista puede estar vacía?
- ¿se permiten elementos repetidos?
- ¿importa el orden?
- ¿existe alguna restricción de rendimiento?
- ¿puedo asumir algún formato específico?
Por ejemplo, si el problema involucra una lista de elementos, puedes decir:
“Antes de proponer la solución, quisiera confirmar algunas reglas. ¿Se permiten elementos repetidos? ¿La entrada puede estar vacía? ¿Es necesario preservar el orden original?”
Esto demuestra cuidado. Y, de paso, evita implementar una solución para un problema que entendiste a medias.
Discusión sobre proyectos y experiencias anteriores
No toda experiencia relevante proviene de un empleo formal. Para estudiantes, personas junior o en transición, los proyectos de universidad, cursos, bootcamps, voluntariados, trabajos freelance, estudios guiados y proyectos personales pueden generar buenas conversaciones.
El objetivo no es haber trabajado en un “sistema gigante con millones de usuarios”. El objetivo es poder explicar:
- cuál era el contexto;
- qué problema intentaba resolver el proyecto;
- cuál fue tu participación;
- qué decisiones tomaste;
- qué dificultades aparecieron;
- qué aprendiste.
Si nunca participaste en un proyecto empresarial real, aun así puedes construir experiencia con proyectos más cercanos a la práctica. El artículo sobre cómo involucrarte de lleno en un proyecto real puede ayudarte a pensar en experiencias más concretas para aprender y luego explicar en entrevistas.
Conversación sobre arquitectura o diseño
Esta etapa es más común en vacantes que requieren cierta experiencia, pero puede aparecer en una versión sencilla para personas junior. En lugar de pedirte “diseña la arquitectura perfecta de Internet”, la conversación puede ser algo como:
“¿Cómo estructurarías una API sencilla para registrar y consultar pedidos?”
Para una persona junior, el objetivo generalmente no es crear la solución más escalable del planeta, con cache distribuido, colas y observabilidad para un problema que todavía no requiere ese nivel de complejidad. El objetivo inicial es organizar el razonamiento.
Puedes comenzar por lo básico:
- ¿qué usuarios utilizan el sistema?
- ¿cuáles son las operaciones principales?
- ¿qué datos deben almacenarse?
- ¿qué integraciones son necesarias?
- ¿qué errores deben tratarse?
- ¿qué partes pueden mantenerse sencillas por ahora?
Aquí, la claridad vale mucho. Una solución sencilla y bien explicada suele ser mejor que un diseño lleno de palabras bonitas que no puedes defender.
Prepárate para entrevistas técnicas a partir de la vacante
Una preparación realista comienza con la descripción de la vacante. Antes de abrir varias pestañas e intentar aprenderlo todo al mismo tiempo, lee con atención:
- stack principal;
- responsabilidades del puesto;
- requisitos obligatorios;
- requisitos deseables;
- contexto del producto, cuando esté disponible;
- nivel esperado para la vacante;
- forma de trabajo del equipo.
Después, separa los temas por prioridad. Lo que aparece como responsabilidad central debe estar antes que lo que aparece como “diferencial” o “deseable”.
Por ejemplo, si la vacante es para desarrollo backend con Node.js, API REST, base de datos relacional y pruebas, quizá tenga sentido priorizar:
- fundamentos de JavaScript o TypeScript;
- creación y consumo de API;
- HTTP;
- modelado básico de datos;
- consultas SQL;
- pruebas automatizadas;
- manejo de errores;
- Git y flujo de versionado.
Por otro lado, si la vacante menciona una herramienta deseable que nunca has utilizado, no intentes “aprender toda la tecnología” en pocos días. Es más honesto comprender lo básico, saber decir que todavía no tienes experiencia profunda y explicar cómo estudiarías o aplicarías esa herramienta.
Esta honestidad ayuda por dos motivos. Primero, evita que generes una expectativa falsa sobre tu nivel de dominio. Segundo, demuestra una habilidad importante en el trabajo real: saber delimitar lo que conoces, lo que todavía necesitas investigar y cómo piensas avanzar.
Una rutina sencilla de preparación
No necesitas transformar la semana de la entrevista en un retiro monástico con café frío y culpa. Una rutina pequeña y constante suele funcionar mejor.
Una estructura posible:
-
Repasa los fundamentos del lenguaje y de las tecnologías solicitadas
Enfócate en lo que realmente puedes explicar. Tipos, estructuras de datos básicas, funciones, clases, módulos, manejo de errores, operaciones asíncronas y consultas comunes, según el stack. -
Practica problemas pequeños de lógica e implementación
Elige ejercicios cortos. El objetivo no es convertirte en atleta olímpico de los algoritmos, sino practicar la lectura del enunciado, la descomposición del problema y una implementación tranquila. -
Repasa tus proyectos y organiza historias para contar
Haz una lista de proyectos relevantes y prepara ejemplos. Incluso los proyectos pequeños pueden generar buenas conversaciones si sabes explicar las decisiones y los aprendizajes. -
Simula explicaciones en voz alta
Elige un concepto y explícalo como si estuvieras conversando con alguien. Graba un audio, habla a solas o practica con otra persona. Al principio parece extraño, pero ayuda mucho. -
Investiga la empresa, el producto y el formato del proceso
Entiende mínimamente qué hace la empresa y prepara preguntas. La entrevista también es una forma de evaluar el contexto.
Una rutina semanal adaptable podría ser:
- Dos momentos para fundamentos y práctica técnica: repasar conceptos y resolver ejercicios pequeños.
- Un momento para repasar proyectos: elegir historias y estructurar respuestas.
- Un momento para simular una conversación: explicar en voz alta, responder preguntas probables y practicar la claridad.
El trade-off aquí es profundidad frente a cobertura. Cubrir muchos temas superficialmente puede dar una sensación de avance, pero no siempre genera seguridad. Priorizar los requisitos más frecuentes de la vacante suele ser más útil, especialmente cuando el tiempo es limitado.
Practica el razonamiento en voz alta durante los desafíos técnicos
En los desafíos técnicos, la comunicación importa porque la persona entrevistadora generalmente no observa solo el resultado final. Quiere entender cómo llegaste hasta allí.
Imagina dos situaciones:
- La Persona A permanece en silencio durante bastante tiempo y escribe una solución casi correcta, pero nadie entiende el camino.
- La Persona B explica el problema, pregunta por las restricciones, propone una solución sencilla, implementa una parte, detecta un caso límite y ajusta la solución.
Aunque la solución de la Persona B no quede perfecta, la conversación generó mejores señales sobre razonamiento, colaboración y capacidad para lidiar con feedback.
Este es un punto en el que las habilidades interpersonales aparecen de forma muy concreta. En una entrevista técnica, las “soft skills” no significan hablar bonito para compensar la falta de conocimientos técnicos. Significan escuchar el problema, confirmar que lo entendiste, explicar decisiones, reconocer límites y colaborar con la persona entrevistadora durante la resolución. El video Domina las soft skills, del canal de la comunidad, complementa bien esta discusión sobre comunicación y actitud profesional.
Un guion práctico para los ejercicios:
-
Repite el problema con tus propias palabras
“Entonces, si entendí bien, debo recibir una lista de elementos y devolver solo los elementos únicos, manteniendo el orden original. ¿Es así?” -
Haz preguntas sobre las reglas y restricciones
“¿La lista puede estar vacía?”
“¿Los elementos siempre son strings?”
“¿Importa la diferencia entre mayúsculas y minúsculas?” -
Menciona una solución inicial sencilla
“Un primer enfoque sería recorrer la lista y guardar los elementos que ya hemos visto.” -
Implementa o detalla el enfoque
Avanza paso a paso. Si estás programando, explica las decisiones importantes sin narrar cada tecla. -
Prueba mentalmente casos comunes y casos límite
“Con una lista vacía, el resultado debe estar vacío.”
“Con elementos repetidos, solo aparece el primero.”
“Con un solo elemento, debe devolverse ese elemento.” -
Evalúa mejoras, si hay tiempo
“Esta solución funciona bien para entradas pequeñas. Si la lista fuera muy grande, me preocuparía por…”
Este guion también ayuda cuando te bloqueas. Y bloquearse pasa. Nadie obtiene superpoderes solo porque abrió un editor compartido.
Cuando no sepas algo, intenta actuar así:
- sé honesto sobre lo que no conoces;
- relaciónalo con algo parecido que ya hayas utilizado;
- explica cómo investigarías o validarías la respuesta;
- pide una pequeña aclaración si la pregunta es ambigua.
Por ejemplo:
“Todavía no he utilizado esta biblioteca específica en un proyecto, así que no quiero fingir que la domino. Pero ya trabajé con una herramienta parecida para validar datos. Comenzaría revisando la documentación de la API principal, prepararía un ejemplo pequeño y escribiría una prueba para confirmar el comportamiento.”
Esto es mucho mejor que inventar una respuesta segura y esperar que nadie lo note.
Dos cuidados importantes:
- no permanezcas en silencio demasiado tiempo por miedo a parecer inseguro;
- no defiendas una solución como si fuera un castillo medieval si la persona entrevistadora te ha dado feedback, pistas o nueva información.
Una entrevista técnica también evalúa la colaboración. A veces, la pista que se ofrece a mitad del camino forma parte de la dinámica. Si ignoras la pista para “demostrar” que puedes hacerlo todo solo, pierdes la oportunidad de mostrar algo más cercano al trabajo real: construir una solución con otras personas.
Convierte tu experiencia en ejemplos claros
Muchas personas junior creen que “no tienen experiencia” porque todavía no han trabajado formalmente como desarrolladoras. Pero la experiencia relevante puede venir de otros lugares.
Puedes hablar sobre:
- proyecto universitario;
- trabajo de fin de carrera;
- proyecto de un curso;
- desafío de bootcamp;
- sistema creado para una persona conocida;
- contribución a un proyecto voluntario;
- trabajo freelance pequeño;
- proyecto personal;
- estudio guiado en el que implementaste algo desde cero.
El secreto es pasar de “hice un proyectito” a una explicación con contexto.
Un modelo sencillo:
- Contexto: ¿cuál era la situación?
- Objetivo: ¿qué debía resolver el proyecto?
- Acción: ¿qué hiciste?
- Resultado: ¿qué funcionó, aunque fuera algo pequeño?
- Aprendizaje: ¿qué harías diferente hoy?
Qué repasar en cada proyecto
Antes de la entrevista, elige algunos proyectos y responde:
- ¿Qué problema resolvía el proyecto?
- ¿Cuál fue tu participación específica?
- ¿Qué tecnologías se utilizaron?
- ¿Qué decisiones técnicas tomaste?
- ¿Qué dificultad apareció?
- ¿Cómo investigaste o resolviste el problema?
- ¿Qué harías diferente hoy?
- ¿Qué parte entiendes lo suficientemente bien como para explicarla?
Por ejemplo, imagina un proyecto de estudio con una API para registrar libros. Una respuesta vaga sería:
“Hicimos una API con una base de datos.”
Una respuesta mejor sería:
“Participé en una API para registrar libros como parte de un proyecto de curso. Mi parte fue crear los endpoints de registro y listado. Una decisión que discutimos fue separar la validación de los datos antes de guardarlos en la base de datos, porque estaban llegando registros incompletos. También tuvimos un error de integración porque el frontend enviaba un campo con un nombre diferente al esperado. Para investigarlo, usamos logs sencillos y probamos la solicitud de forma aislada. Hoy añadiría pruebas para cubrir este tipo de contrato entre la entrada y la salida.”
Observa que el proyecto no tiene que ser enorme. La explicación muestra participación, decisión, problema, investigación y aprendizaje.
En los trabajos grupales, cuidado con utilizar eternamente el “nosotros hicimos”. Es evidente que los proyectos son colectivos, pero la entrevista necesita comprender tu contribución. Puedes decir:
“El proyecto fue grupal. La parte en la que participé más directamente fue…”
Esto evita exagerar, pero también evita borrar tu participación.
También existe un trade-off entre confianza y honestidad. Debes mostrar claramente lo que sabes, pero sin exagerar tu dominio sobre herramientas o decisiones que todavía estás aprendiendo. Decir “tengo nociones y ya implementé un caso sencillo” es diferente de decir “lo domino completamente” después de un tutorial de una tarde.
Antes, durante y después: comportamientos que ayudan en el proceso
La preparación técnica importa, pero el proceso no comienza cuando aparece la primera pregunta. Algunas actitudes antes, durante y después ayudan bastante.
Antes de la entrevista
Confirma la información práctica:
- formato de la etapa;
- duración;
- herramienta utilizada;
- si habrá código en vivo;
- si puedes consultar la documentación;
- idioma de la conversación;
- quién participará, si la empresa lo informa;
- próximos pasos del proceso.
En las entrevistas remotas, prepara el entorno:
- conexión;
- micrófono;
- cámara, si vas a utilizarla;
- editor o IDE;
- navegador;
- permisos de la plataforma;
- un lugar con menos interrupciones.
No hace falta montar un estudio de cine. Pero abrir la herramienta poco antes y descubrir que no carga es una emoción innecesaria.
Prepara también preguntas para la empresa. Por ejemplo:
- ¿Cómo es la rutina del equipo?
- ¿Cómo recibe acompañamiento una persona junior?
- ¿Cómo se realizan las revisiones de código?
- ¿Cuáles son los principales desafíos técnicos del producto en la actualidad?
- ¿Qué se esperaría de la persona contratada durante los primeros meses?
- ¿Cómo trabaja el equipo con el aprendizaje y el feedback?
La entrevista es una vía de doble sentido. Tú también estás evaluando si ese contexto encaja con tu momento.
Durante la entrevista
Durante la conversación:
- pide aclaraciones cuando sea necesario;
- administra el tiempo;
- explica lo que estás pensando;
- reconoce tus límites;
- acepta el feedback;
- confirma que han entendido lo mismo;
- evita fingir conocimientos que no tienes.
Si percibes que estás siguiendo un camino equivocado, di:
“Creo que mi enfoque inicial está complicando más de lo necesario. ¿Puedo retroceder un paso e intentar una solución más sencilla?”
Esto puede ser positivo. Muestra capacidad de revisión.
Si aparece el nerviosismo, intenta volver a lo básico: entender el problema, dividirlo en partes más pequeñas y comunicar el siguiente paso. No necesitas parecer una enciclopedia ambulante. Necesitas participar en la conversación con honestidad y claridad.
Después de la entrevista
Después de la entrevista, registra rápidamente:
- qué temas aparecieron;
- en qué tuviste dificultades;
- qué preguntas fueron sencillas;
- qué ejemplos tuyos funcionaron bien;
- qué tema estudiar después;
- qué dudas quedaron sobre la empresa.
Este registro ayuda a convertir cada proceso en aprendizaje. Pero cuidado con transformar cada resultado en un juicio definitivo sobre tu capacidad.
Una entrevista difícil o un rechazo no demuestra que “no sirves para el área”. Puede indicar un desajuste con la vacante, un formato deficiente, nerviosismo, una expectativa diferente, falta de preparación en algún tema específico o simplemente competencia. Utiliza el feedback, cuando exista, como información, no como sentencia.
También tiene sentido agradecer y seguir las indicaciones sobre el contacto posterior que haya dado la empresa. Si la empresa no estableció un plazo, puedes preguntar de forma objetiva por los próximos pasos. Sin exigir de forma agresiva, desaparecer por desesperación ni enviar un pergamino diario.
Próximos pasos
Si estás preparándote para entrevistas técnicas ahora, un camino práctico sería:
- Elige una vacante real o una descripción parecida a tu objetivo.
- Enumera los requisitos principales y separa los temas por prioridad.
- Repasa los fundamentos del stack más importante.
- Resuelve ejercicios pequeños explicando el razonamiento en voz alta.
- Elige dos o tres proyectos tuyos y organiza historias con contexto, acción, resultado y aprendizaje.
- Simula una conversación técnica con alguien o graba tus respuestas.
- Después de cada entrevista, registra lo aprendido sin atacarte.
Al final, una preparación constante no elimina las imperfecciones de los procesos de selección. Seguirá habiendo entrevistas extrañas, preguntas mal formuladas y días en los que aparezcan los nervios. Sin embargo, estudiar con dirección, practicar la comunicación y organizar tu experiencia aumenta tu claridad y tus recursos.
Y eso es muy diferente de memorizar respuestas preparadas.
Participa en la comunidad SCCB para seguir conversaciones y eventos enfocados en la práctica profesional del software.
